Як записати зміни на сервері?

Отже, у нас, мабуть, була така ситуація: ви налагоджуєте якусь проблему, лише зрозумівши, що її викликала зміна конфігурації, яку ви зробили півроку тому, і ви не можете згадати, чому це зробили. Тож ви скасуєте це та вирішите проблему, а тепер повертається якась інша проблема. О так, зараз я пам’ятаю! Тоді ви правильно це виправите.

Це тому, що ти не зробив належних записок, дурень! Але який хороший спосіб це зробити?

В інженерії ми маємо багато програмного забезпечення, яке допомагає нам виявляти та відстежувати зміни. Контроль джерел, огляди коду тощо. Кожна зміна відстежується, кожна зміна вимагає коментаря щодо того, що це таке. А типові відділи інженерії вимагають хороших коментарів, щоб через шість місяців, коли ви з'ясували, чому ви зламали його так, ви могли використовувати історичну функцію "вини" або двійкові пошукові побудови, щоб точно визначити проблему. Ці інструменти - це дуже ефективні засоби комунікації та історичні записи.

Але в серверній країні у нас є 500 різних сервісів, які мають різні способи їх налаштування. І вони не завжди мають текстовий формат (враховуйте налаштування дозволів на папку чи зміну місця розташування файлу сторінки), хоча вони можуть мати текстове подання.

У нашому середовищі ми перевіряємо, які конфігураційні файли ми можемо перетворити на Perforce, але таких дуже мало. Не можу точно перевірити в БД Active Directory. Хоча, можливо, дамп, який може бути різним ...

Раніше я намагався вести журнал змін вручну у нашій вікі, але дуже важко підтримувати дисципліну для цього (я знаю, це не гарний привід, але це справді важко).

МОЕ ПИТАННЯ: Які стратегії та інструменти ви використовуєте для вирішення цієї проблеми відстеження змін конфігурації на ваших серверах?

- Оновлення -

Примітка. Я не шукаю інструментів для спільного користування нотами (я знайомий з OneNote тощо) настільки, як автоматизовані інструменти, спеціально призначені для допомоги у відстеженні змін на сервері. Немає всебічного інструменту для відстеження змін конфігурації сервера, але, можливо, є деякі для конкретних додатків, таких як GPO.

Також мене дуже цікавлять конкретні стратегії, які ви вважаєте корисними. "Ми ділимось нотами в Sharepoint" досить невиразно. Як ви підтримуєте дисципліну? Який формат ви використовуєте для відстеження змін? Як ви впорядковуєте свої зміни? Я б дуже хотів прикладів, а також ідей.

У Linux Linux люди переслідують декілька різних стратегій:

• Системи обмежень конфігурації , як Cfengine або маріонетка або кухар . Вони схожі на Windows GPO. Слід зазначити, що вся конфігурація сервера навмисно задокументована в одному місці, і ви знаєте, на яку деталізацію (серверну кімнату, групу, конкретний сервер) застосовується політика. Це не врятує вас від того, "що, пекло, було різним півроку тому?" але це дозволяє просто занурити конфігурацію сервера і відновити з нуля. Ви можете поставити політику cfengine та marpet під контролем редагування, щоб відповісти на питання.
• Контроль редакції / тощо . Зазвичай програми Linux зберігають їх конфігурацію в одному місці / тощо. Сміливі починають писати сценарії, щоб поставити / etc на контроль редагування. Однією з таких програм, про які я знаю, є etckeeper :

Опис: зберігати / тощо в git, mercurial, bzr або darcs
 Програма etckeeper - це інструмент для збереження / etc зберігання в git, mercurial,
 сховище bzr або darcs. Він підключається до APT, щоб автоматично здійснювати зміни
 зроблено до / тощо під час оновлення пакету. Він відстежує метадані файлу цієї версії
 системи управління зазвичай не підтримують, але це важливо для / тощо
 як дозволи / etc / shadow. Це досить модульно і налаштовується
 також простий у використанні, якщо ви розумієте основи роботи з версією
 контроль.

Однією з проблем у цій ситуації є те, що насправді це комбінований бізнес-процес / технологічна проблема. І це, безумовно, більше, ніж просто відстежувати, що змінив адміністратор. Також потрібно стежити за несподіваними змінами та хорошою координацією між адміністраторами або підрозділами, щоб зміна контролера AD не порушила налаштування дозволів бази даних на якомусь відомчому сервері. Тобто, ваше питання - це гігантська банка глистів :)

У моїй організації ми приблизно рік розробляємо процеси та системи для вирішення цього питання. З боку бізнес-процесів ми сформували команду управління змінами. Відповідно до SOP, всі зміни виробничого середовища координуються через них. Вони збирають усі зміни, разом із сферою застосування, системами, на які впливають послуги, тощо. Забезпечуйте хорошу документацію щодо змін, а також плани розгортання та відкат. Приймайте щотижневі (відкриті) зустрічі, щоб переглядати майбутні зміни в оточенні, а потім надсилайте електронні листи з детальною інформацією про всі ці зміни. Кінцева мета цього процесу полягає в тому, щоб, фактично, всі фахівці в галузі інформаційних технологій знали все, що відбувається. Це допомагає зупинити проблему, наприклад, SysAdmin встановити патч ядра та перезавантажити систему, яка зніме базу даних часових годин.

Щодо технологічної сторони, я можу говорити лише про хлопців Unix / Linux, оскільки я не маю справу з Windows. Вони впроваджують Puppet від Reductive Labs для управління конфігурацією всіх цих систем. Просто, це система клієнт / сервер, де кожен визначає конфігурацію машини на сервері, і клієнт так часто вилучає такі шанси (за замовчуванням 30 хвилин). Крім того, якщо є шанси на керування файлами локально, вони також повертаються назад у той час. Ми використовуємо його для управління запущеними службами, конфігураціями брандмауера, авторизацією користувачів тощо.

Я також рекомендую вивчити щось на зразок TippingPoint. Це клієнтська служба, яка спостерігає за конфігурацією системи та надсилає сповіщення про зміни. Це робить нас людьми безпеки найбільш щасливими. Він значною мірою використовується для відстеження шкідливих чи неопублікованих змін.

Я був у 4 або 5 компаніях зараз, я не дуже пам’ятаю.

У всіх нас була ця проблема. Ніхто з нас не вирішив це на 100 відсотків, але в компанії, на якій я зараз, ми маємо те, що, на мою думку, є найкращою стратегією на сьогоднішній день.

Sharepoint / Wiki / Evernote / PIN-коди

• Ділитися думкою
  • стогін все, що ви хочете ... він має деякі дуже приємні функції списку.
  • Списки IP-адрес
  • інвентар
  • сервісні рахунки та використання
  • зміни журналів сповіщень
• Wiki
  • Спосіб роботи
  • списки завдань із великим діапазоном
• Evernote
  • ми з партнером використовуємо це, щоб розмістити все, що ми не хочемо, у Вікі
  • більше практичних, які мають технічний характер
  • подряпини, які нам обом потрібно бачити
  • облік завдань за тиждень
  • списки завдань підрядника
  • clipper evernote дозволяє легко знімати налаштування AD / прав екрану на екрані
  • доступні скрізь
• PIN-коди
  • Сховище паролів

Для деяких із них є, мабуть, кращі інструменти, але це те, що ми використовуємо:

• Відстежуйте зміни конфігурації та оновлення / виправлення на кожному сервері в приватній вікі
• Також зберігайте практичні запити та проблеми у вирішенні проблем / рішень
• Використовуйте Sharepoint або Google Документи, щоб зберігати авторитетні копії речей, таких як статичні IP-списки
• використовувати Subversion для відстеження змін у файлах конфігурації

Для Windows ознайомтесь із серією Microsofts System Center або будь-якого іншого конкурента з налаштування та управління сервісом для цієї платформи.

Зміни повинні бути направлені через гідну процедуру управління змінами, яка сама по собі затверджує та записує їх до того, як вони фактично виконані. Це може бути 100% посібник для початківців. За допомогою деяких кращих інтегрованих інструментів ви можете попросити інструмент зробити фактичні зміни та отримати "автоматичне" вхід із нього в базу даних центральної конфігурації - а не голими руками в консоль окремого сервера, перекопуючи налаштування вручну спробуйте виправити проблему з ковбойським стилем.

Ви абсолютно повинні мати процес управління змінами, особливо якщо є кілька людей, які мають можливість / доступ вносити зміни на системному рівні у вашому оточенні. Це також дає можливість керівництву відмовитися від можливих змін, однак його зворотний бік викликає затримку в процесі змін, якщо ви не можете вносити зміни в літній час.

Деякі способи відстеження змін можуть включати перевірку подій у вашій SEM (якщо припустити, що у вас є менеджер подій безпеки) або такі інструменти, як Nessus (за допомогою великої роботи можна перевірити ваше середовище, щоб знайти зміни).

Це більш локалізована відповідь на основі * nix. Я не знайшов жодних хороших інструментів, щоб наслідувати його під Windows.

Є декілька способів цього здійснити ... і зловити це, коли забудеш.

Системи контролю версій, такі як subversion, git, cvs або RCS - хороший спосіб відстеження історії конфігураційного файлу. Якщо ви не хочете встановлювати систему керування ревізією на своїх виробничих серверах, зберігання каталогів файлів конфігурації локально або віддалено, використовуючи щось на зразок rsnapshot , дасть вам більшість переваг RCS, але ви втрачаєте можливість перевірки або залишення комісії журнали (хоча це можна вирішити з коментарями всередині самих файлів).

Щоб допомогти вам запам’ятати реєстрацію змін, автоматичне звітування про зміни конфігурації за допомогою щонічного запуску пробіжної проводки - це хороший початок. Після побудови бази даних tripwire про поточний стан файлів, будь-яка зміна в них призведе до електронного листа під час наступного запуску. Ви будете продовжувати отримувати цю пошту, поки база даних не буде оновлена, таким чином "скидання" трикутника.

Я б використовував систему відстеження проблем, таку як flyspray (будь-яка, але мені подобається flyspray для непрограмуючих матеріалів). Перш ніж хто-небудь торкнеться конфігурації, слід покращити / проблему. Коли ви виправляєте / впроваджуєте це, зміни вносяться у квитку.

Вікі може приємно задокументувати поточну установку, але її легко застаріти - і, здається, потрібно більше зусиль для оновлення IMO.

Ви не збираєтесь знайти щось автоматизоване для цього - хоча ви, ймовірно, могли це налаштувати, щоб зміни певних конфігураційних файлів автоматично надсилалися електронною поштою до трекера проблем, якщо хочете.

Я думаю, що це лише питання хорошої політики, інструментів і дисципліни з низьким рівнем бар'єру.

Ми створили щось домашнє, щоб зробити відстеження змін у нашому середовищі; це не щось надскладне, і працює досить добре.

• Політика самоуправління полягає у встановленні, що будь-які зміни, які, за вашою оцінкою, або відхиляються від нестандартних установок або можуть потенційно спричинити проблеми, повинні бути задокументовані в системі змін.
  • Зворотний бік цієї "монети" - це якщо ви вирішите проблему, знайдіть останні або пов'язані записи змін.
• Увійдіть у систему та виберіть сервер, службовий або апаратний компонент, який ви змінюєте
  • компоненти попередньо вводяться в ту саму систему з базовою "демографічною" інформацією (місцезнаходження, постачальник, серійний номер, відповідальний відділ)
• Виберіть зі спадного списку основних категорій
  • Позапланові простої
  • Виправлення
  • Обслуговування обладнання
  • Встановлення програмного забезпечення
• Вкажіть деталі того, що ви робили, бачили, спостерігали
• копія надсилається відповідальній стороні і зберігається як XML-файли, які індексуються пошуковим пристроєм.
• Прибуток

Як я вже казав, нічого фантазійного. Він використовує PERL CGI (написаний мільярд років тому) та пристрій пошуку Google для індексації.

Недоліки:

• З групами сервісів важко працювати, наприклад, ви просто додали один і той же патч до всіх 25 своїх контролерів домену; у нас немає групи "Контролер домену", тому нам потрібно вручну їх вибрати
• Не інтегрується з апаратним, програмним забезпеченням або повідомленнями про помилки журналу подій, щоб допомогти у вирішенні проблем
• відповідно, введення даних вручну для всіх "демографічних" даних, як я вже говорив вище

У будь-якому разі, якщо все-таки вас зацікавив би код, дайте мені знати, і я, мабуть, зможу його захопити, щоб поділитися.

Як було сказано, це часто культурна проблема - зрештою, деякі магазини розвитку вже не заважають коментарям (самодокументація коду є модною модницею сьогодні!), А деякі використовують систему контролю версій як священний граал історичних записів. Очевидно, це не ідеально.

Отже, єдиний вірний спосіб виправити це - зробити це культурним рішенням. Переконайтеся, що всі причини змін внесені в трекер помилок (або в базу знань, або у вікі), і переконайтеся, що всі зміни реєструються в системі управління змінами.

У нас є клієнти служби екстреної допомоги, кожна зміна, яка відбувається з їхньою системою, реєструється, і кожного разу, коли ми входимо в їх систему, ми повинні реєструвати її. Для деяких з них нам потрібно спершу зателефонувати за дозволом (і, мабуть, вони теж ввійшли!). Кожна зміна реєструється, і змінити систему клієнта без реєстрації буде дисциплінарним правопорушенням.

Це звучить обтяжливо, але це не так. Ви швидко впадаєте у звичку додавати себе до журналу доступу та журналу змін - це не гірше, ніж потрібно писати коментар під час перевірки зміни коду.

Я рекомендую багтейкер як журнал причин зміни змін, оскільки їх зазвичай легко оновлювати (я використовую Mantis).

Якщо ви шукаєте «рішення для підприємств» (тобто у вас більше грошей, ніж у Бога, і хочете мати дійсно класний інструмент), інструмент, який я використовував для підтримки та надання роботи на місці, робить це як одну з його багатозначних особливостей.

Поняття не має, що таке базове ціноутворення, але перш ніж HP придбала Opsware, це було ~ 350 000 доларів США (без підтримки, і повірте - ви хотіли підтримки, коли я починав з Opsware).

Кілька клієнтів, у яких я працював, використовували параметри конфігурації додатків та знімків у поєднанні з Tripwire .

Звичайно, якщо у вас немає бюджету - це поганий вибір ™ :)

І, fwiw, реклама, яка з’явилася вгорі цієї сторінки для мене, коли я перезавантажувала її, була для спецій . Схоже на HPSA :)

Якщо все, що ви хочете зробити, це відстежувати зміни та не керувати усім процесом (тобто за допомогою шеф-кухаря чи лялечки), просто rsyncваш etcкаталог (де б це не було) в локальний git repo.

for HOST in alpha bravo charlie delta ...; do

    rsync -avz --exclude-from=exclusions -e ssh admin@$HOST:/opt/local/etc/ ./$HOST

done

Ви, звичайно, можете додавати інші джерела за потребою.