Як програміст, ми схильні сприймати сисадмін як належне. Кілька разів, коли я був без гарного сисадміна, по-справжньому змусив мене оцінити те, що ви робите. Коли ми заходимо в навколишнє середовище без сисадміна, які слова мудрості ви можете нам запропонувати?
Відповіді:
Я б почав із:
<вставити сюди велику відмову від відповідальності>
Деякі з них були сказані раніше, але варто повторити.
Документація:
Документуйте все. Якщо у вас немає, встановіть вікі, що не знаходяться на радарі, але переконайтеся, що ви створили резервну копію. Почніть з збирання фактів, і одного дня сформується велика картина.
Створіть діаграми для кожного логічного відрізка і оновлюйте їх. Я не міг підрахувати, скільки разів мене врятувала точна мережева карта або кластерна діаграма.
Тримайте журнали збирання для кожної системи, навіть якщо це просто копіювати та вставляти команди для її створення.
Під час створення вашої системи встановіть та налаштуйте ваші програми, протестуйте, чи вона працює, і виконайте свої показники. Тепер витріть диски. Серйозно. 'dd' перший мегабайт з передньої сторони дисків або іншим чином поле зробить незавантаженим. Годинник тикає: доведіть, що ваша документація може відновити її з нуля (а ще краще, доведіть, що ваш колега може нічого, крім вашої документації). Це складе половину вашого плану відновлення після стихійних лих.
Тепер у вас є перша половина вашого плану відновлення після катастроф, документуйте решту; як повернути стан програми (відновити файли зі стрічки, перезавантажити бази даних з дампсів), деталі постачальника / підтримки, вимоги мережі, як і де отримати обладнання для заміни - все, що ви можете придумати, допоможе відновити систему.
Автоматизація:
Моніторинг:
Приладобудування - це чисте золото. Можливість перегляду транзакцій, що проходять через систему, набагато простішає налагодження та усунення несправностей.
Створіть цілі тести, які доводять не лише те, що програма жива, але й справді робить те, що їй належить. Окуляри ваші, якщо їх можна ввести в систему моніторингу для оповіщення. Це служить подвійним обов'язком; окрім доведення роботи програми, це значно покращує оновлення системи (моніторингові системи звітів зелені, оновлення працювало, час повертатися додому).
Бенчмарк, відстежуйте та збирайте метрики щодо всього, що потрібно зробити для цього. Тести підказують, коли очікувати, що щось випустить чарівний дим. Моніторинг повідомляє, коли він є. Показники та статистика полегшують отримання нового набору (зі свіжим чарівним димом) через управління.
Якщо у вас немає системи моніторингу, застосуйте її. Бонусні бали, якщо ви дійсно зробите в ньому вищезазначені тести.
Безпека:
"chmod 777" (він же надає весь доступ / привілеї) ніколи не є рішенням.
Підпишіться на принцип «найменшого розряду»; якщо він не встановлений, скопійований або іншим чином не знаходиться на диску, він не може отримати компрометацію. "Кухонна мийка" встановлення ОС та програмного забезпечення може полегшити життя під час фази збирання, але ви в кінцевому підсумку заплатите за це.
Знайте, для чого призначений кожен відкритий порт на сервері. Аудіюйте їх часто, щоб переконатися, що не з’являються нові.
Не намагайтеся очистити зламаний сервер; її потрібно перебудувати з нуля. Перебудуйте на запасний сервер із щойно завантаженими носіями, відновивши лише дані з резервних копій (оскільки бінарні файли можуть бути порушені) або клонуйте скомпрометований хост десь ізольовано для аналізу, щоб ви могли відновити один і той же комплект. Навколо цього існує цілий юридичний кошмар, тому помиляйтесь на стороні збереження у випадку, якщо вам потрібно буде дотримуватися законних шляхів. (Примітка: IANAL).
Обладнання:
Ніколи не припускайте, що щось зробить те, що написано на коробці. Доведіть, що робить те, що вам потрібно, на всякий випадок, якщо цього не зробити. Ви побачите, що говорите "це майже працює" частіше, ніж ви очікували.
Не скупіться на віддалене керування обладнанням. Серійні консолі та управління освітленням слід вважати обов'язковими. Бонусні бали за дистанційно керовані смуги живлення за ті часи, коли у вас немає можливості.
(Убік: Існує два способи вирішити проблему о 3 ранку. Один із них - теплий, робота над ноутбуком над VPN у вашій піжамі, інший - товста куртка та приїзд до центру даних / офісу. Я знаю, який з них я віддайте перевагу.)
Управління проектами:
Залучіть людей, які будуть підтримувати систему з першого дня життєвого циклу проекту. Час проведення часу та мозку може і здивує, і немає сумнівів, що вони (повинні?) Матимуть стандарти або вимоги, які стануть проектними залежностями.
Документація є частиною проекту. Ви ніколи не отримаєте час написати всю справу після закриття проекту та переходу системи на технічне обслуговування, тому переконайтеся, що воно включено як зусилля на графік на початку.
З першого дня впроваджуйте планове застарівання в проект та розпочніть цикл оновлення за півроку до дня вимкнення, який ви вказали в проектній документації.
Сервери мають певний термін експлуатації, коли вони придатні для використання у виробництві. Кінець цього терміну експлуатації, як правило, визначається так, як завжди, коли постачальник починає стягувати плату за щорічне обслуговування, ніж коштуватиме оновлення комплекту, або близько трьох років, залежно від того, що коротше. Після закінчення цього часу вони чудово підходять для середовищ розробки / тестування, але вам не слід покладатися на них для ведення бізнесу. Перегляд навколишнього середовища за 2 1/2 роки дає вам достатньо часу, щоб перейти через необхідні управлінські та фінансові обручі для того, щоб замовити новий комплект і здійснити плавну міграцію, перш ніж відправити старий комплект великому постачальнику в небо.
Розробка:
Резервні копії
Дані, які ви не створюєте резервну копію, - це дані, які ви не хочете. Це непорушний закон. Переконайтесь, що ваша реальність відповідає цій.
Резервні копії складніше, ніж вони виглядають; деякі файли будуть відкритими або заблокованими, тоді як інші потрібно припинити, щоб сподіватися на відновлення, і всі ці проблеми потрібно вирішити. У деяких пакетах резервного копіювання є агенти чи інші методи роботи з відкритими / заблокованими файлами, інші - не. Скидання баз даних на диск і резервне копіювання цих файлів вважається однією з форм "припинення", але це не єдиний метод.
Резервні копії не потрібні, якщо вони не пройшли тестування. Кожні кілька місяців витягуйте випадкову стрічку з архівів, переконайтеся, що в ній фактично є дані, а дані узгоджуються.
І найголовніше ...
Виберіть свої режими відмов, інакше Мерфі буде ... і Мерфі не працює за вашим графіком.
Дизайн для відмов, документуйте розроблені слабкі моменти кожної системи, що викликає їх і як відновити. Все зміниться, коли щось піде не так.
Не вважайте, що це просто. Я знаю багатьох програмістів, які думають, що тільки тому, що вони можуть встановити IIS або Apache там, де розроблено вікно, що вони можуть запустити веб-ферму. Зрозумійте, що передбачає робота, і займайтеся своїми дослідженнями та плануванням, не думайте, що робота над системою управління - це легка річ, яку ви можете зробити за 10 хвилин, щоб розгорнути додаток.
Безпека не є думкою. Хоча зламана програма може змусити програміста виглядати некомпетентним, це (принаймні) втрачені вихідні, проведені на перевірку, очищення та / або відновлення з резервних копій для системного адміністратора.
З цього приводу не слід розглядати резервні копії як контроль версій. Вони призначені для відновлення після аварій, і насправді не призначені для відновлення коду, оскільки ви забули, що змінили.
І перестаньте сліпо звинувачувати оновлення Windows за те, що ваш код порушено. Мені байдуже, що це спрацьовувало добре, скажи мені, чому це не працює зараз - тоді ми можемо побачити, чия це вина.
Як налагодити проблеми з мережею та спостерігати за запуском програми за допомогою інструментів sysadmin. Як програміст, який почав працювати в системному адмініструванні, я вражений тим, як безсилі багато програмістів стають, як тільки мережа "просто припиняється".
openssl s_client -connect target-host:portколись) для ручного підключення до мережевих службЗнайте, як вирішити проблеми.
Дуже легко передати долар (наприклад, ваша мережа шлакує моє спілкування з базою даних). Це може бути помилковою мережею, але у вас повинні бути журнали програм із помилками, які за допомогою Google або SO можуть виявити проблему в конфігурації програми.
Всім подобається звинувачувати апаратуру, ОС або мережу, тому, якщо ви будете дотримуватися трохи ретельнішої уваги, ви зробите системного адміністратора щасливою людиною. Тому що, якщо нічого іншого, ви, можливо, зможете вказати їх у конкретному напрямку щодо того, що може бути неправильним (на відміну від того, щоб сказати "ваша мережа смокче" або щось не менш корисне).
Документуйте все, що можете. Не можу сказати, скільки разів останній сисадмін думав, що було б мило не документувати щось для «безпеки роботи», або хтось просто захотів увійти та вийти. Так само, як програміст повинен залишати хороші коментарі, системні адміністратори повинні документувати. Діаграма топології теж непогана.
Документація: не потрібно чітко говорити, але як працює програма, схема, що показує, як біти підходять і способи тестування кожного компонента, коли все йде не так. Зразок даних і вихід хороший.
Вимоги: на які модулі вона покладається? Версії? ОС?
Моніторинг: в ідеалі розробники включатимуть моніторингову інформацію та тести із додатком.
Якщо говорити про упаковку, УПАКОВКА! Нічого гіршого, ніж "розгортання", що означає перевірку нового перегляду файлу з VCS та копіювання його на купу серверів. Занадто часто програмісти не оцінюють складність розгортання програмного забезпечення: є причини, через які пакетоване програмне забезпечення утворює основу більшості ОС.
Якби розробник прийшов до мене з RPM, який встановив вперше із стислою, вичерпною документацією та деякими тестами Nagios, вони були б моїм найкращим другом.
Це може стосуватися лише початківців програмістів, але я маю справу з кількома речами кожного проекту з деякими програмістами.
"Це працює на моїй машині" - це ніколи не є дійсним твердженням. Відповідальність програміста є створити інсталяційну програму для використання на сервері або принаймні документувати всі з'єднання та dll та надбудови, які знадобляться на сервері.
(Я чув це кілька разів, тому, будь ласка, не смійтесь) Я запускаю exe на сервері зі своєї машини, і вона працює. Але коли я запускаю його на сервері (Citrix, Terminal Server тощо), він не працює. Будь ласка, зрозумійте dll та ocx та все інше, що вимагає ваша програма, і де та як вони зареєстровані, і як ваша програма їх використовує.
Це може здатися простим, але я з цим постійно працюю.
Брайан
Гаразд це трохи збивається, але:
а) При кодуванні припустіть, що базова інфраструктура може вийти з ладу, і не походить із суші, щасливого та щасливого. Або Google.
б) Ми, мабуть, не маємо ресурсів, щоб реалізувати щось подібне до інфраструктури, про яку ви читали, тому полегшіть нас, коли все піде на спад. Ймовірно, ми знаємо, що потрібно зробити, але з будь-якої причини це просто ще не сталося. Ми - ваші партнери!
c) Як сказано в jhs, це дійсно допоможе, якби ви ознайомилися з інструментами для усунення несправностей з інфраструктурою, такими як ping, traceroute (або поєднуючи обидва - mtr), dig та ін.
г) Якщо ви програмуєте комп’ютер, ви дійсно повинні знати, як він підключається до мережі, і такі основи, як можливість розбору результатів ipconfig / all або ifconfig. Ви повинні мати можливість налагодити та запустити підключення до Інтернету за мінімальної допомоги.
Інакше я думаю, що Avery дуже прибив її. Деви, які роблять маленький сисадмін, варті своєї ваги в золоті! Але в рівній мірі сисадміни, які розуміють, як розбираються люди (у тому числі версії тощо), дуже важливі в цей день та вік.
Начебто це зараз в ефірі, я помітив більше дискусій про відносини dev / ops у блогах - перевірити
Що жодна група чи функція не є «кращою», ніж інша, і що жоден не потребує «більших мізків», ніж один у одного. Я бачив, як обидві сторони отримують усі примадонні в компанії інших - ви всі намагаєтесь досягти однакових цілей - зосередьтеся на цих подібностях, а не на тому, що ви використовуєте різні інструменти.
Архітектор інфраструктури звернувся до програміста, можливо, захоче відмовити цю транзакцію в майбутньому :)
Як хтось, хто був системним адміністратором для розробників, і сам розробник, поради, що даються тут, є не лише золотом, але повинні бути частиною найманої документації для нових розробників для компаній у всьому світі.
Щось я ще не бачив (пояснював) тим, що розробники дійсно повинні знати продукти, які вони використовуватимуть для створення програм, за які вони платять. Кількість разів, що мені доводилося пояснювати та налаштовувати сервери apache, встановлення eclipse та Visual Studio, а також базу даних на машинах розробників, викликає занепокоєння.