Які речі програміста повинен знати кожен системдмін?

Натхненний цим питанням , я запитую зворотне: скільки про програмування повинні знати системні адміністратори? Більш конкретно, які інструменти програмування корисні для системи sysadmin?

• Контроль версій . Вміти генерувати, читати та застосовувати виправлення. Знайте, як користуватися системою управління версіями, яка представляє широкі версії сховища і чому ви хочете її. Знайте, як писати описові журнали змін і чому їх потрібно. Знайти, як шукати в журналах сховища за ключовими словами та часовими рамками.
• Сценарії . Зробіть щось раз і будьте на шляху. Зробіть це двічі або більше, зробіть це один раз, потім напишіть сценарій.
• Налагодження . Знайте, як прочитати трасування стека та як повідомити про відповідні помилки контакту підтримки програмного забезпечення. Пошук помилки є приємним і корисним, але знаючи, як її виправити, може знадобитися багато коштів для читання коду. Зробіть ту частину, яка вам легка, і дозвольте їм зробити ту частину, яка їм легка.
• Тестування . Контролюйте постійно та записуйте помилки. Використовуючи спільно з контролем і тестуванням версій, ви маєте чітке уявлення про те, що, можливо, пішло не так, коли і що змінилося тоді. Контролюйте як виробництво, так і попереднє виробництво.
• Експертна оцінка . Запропонувати та переглянути зміни у виробничих системах. Тест на попередню продукцію, точно визначте, що потрібно зробити, і запишіть, які послуги можуть впливати на тривалий час. Не дозволяйте Управлінню змін змінитись на політичні битви бюрократичної влади.
• Вивчення криптографії . Сучасний системний адміністратор відповідає за мережеві ресурси; додавання безпеки як завершального кроку знаходиться десь між неможливим і дуже дорогим пропозицією. Розуміння криптографії відкритого ключа, практики обробки паролів та загального шифрування буде надзвичайно цінним.

Я б почав із:

1. Як написати більше, ніж найосновніші сценарії, незалежно від мови. Автоматизація - твій друг.
2. Як запустити налагоджувач / знати, як читати повідомлення про аварійну ситуацію: це дозволяє з’ясувати звіт про аварійну ситуацію і кого запитати, що на двійку значно простіше.
3. Контроль версій - не тільки для коду, але і для всього, що варто зберігати історію або змінювати контроль.

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

Знайте один текстовий редактор. Зазвичай vi для системних адміністраторів, emacs для програмістів.

Знати, як сценарій. Виберіть мову сценарію. Perl - це багаторічний фаворит, як і комбінація shell / sed / awk. Ruby і Python можуть працювати, але для багатьох речей об'єкти є неправильною парадигмою.

Знати, як написати читану документацію.

Контроль версій. Важливе значення для підтримки файлів конфігурації та аудиторських контурів.

Навчіться мислити в плані програмування. Розуміти процедурні, об'єктно-орієнтовані та функціональні парадигми програмування. Їх ніколи не можна використовувати, але знаючи їх, ви робите нескінченно продуктивнішими.

Навчіться використовувати налагоджувач (або більше) та вести журнал.

Навчіться використовувати RDBMS. Існує велика кількість вимог щодо обробки даних, які можна спростити за допомогою правильного використання RDBMS. Навіть можливість перейти на роль DBA за потребою може творити чудеса.

Тест перед розгортанням. Дивіться філософію розвитку, що керується тестом.

Парне програмування добре. Попросіть когось іншого за плечима вивчити / порадити / виправити.

Навчіться, як мінімум, ознайомлюватися з купою мов. Вивчайте нову мову щороку.

• Знати, як програмувати. Так, це важливо: як сказав один із коментаторів, якщо ви це робите не один раз, тоді напишіть сценарій - і напишіть його добре.
• Знайте інструменти, що входять до стандартної установки операційної системи. Для адміністраторів UNIX це означає такі інструменти, як Korn Shell (ksh) та Perl та vi. Не покладайтеся на наявність Emacs або Ruby, Tcl або C оболонки.
• Знайте мережу. Як складаються пакети Ethernet? Як виглядає пакет? Які різні типи пакетів? Ознайомтеся з такими інструментами, як tcpdump, wireshark, snoop та інші.
• Напишіть переносний код. Якщо код запускається під Linux - і Tru64 - і Solaris - і OpenVMS - тоді напишіть переносний код. Навіть якщо він працюватиме в двох версіях UNIX - зробіть його портативним. Але тоді, якщо це не потрібно бути портативним, не витрачайте на це зайвий час.
• Знайте, де знаходиться документація. Для Perl це означає perldoc, Perl Mongers, perl.org і т. Д. Для ksh це означає сторінку людини та ваші улюблені книги Korn-оболонок.
• Документ, документ, документ, документ! Документуйте свій код, створюйте підручні сторінки, створюйте вбудовану документацію Perl та все інше, що підходить. Поясніть, як користуватися програмою і чому ви її закодували саме так.
• Знайте засоби для пакування вашої системи. Знайте, як створити RPM для Red Hat, або депо HP-UX або пакети Solaris: це дозволить вам створити пакети для ваших систем і, таким чином, інтегрувати їх у процес інсталяції.

Сценарій є надзвичайно важливим, але я би другий порадою, що знання деяких "справжніх" мов є певним бонусом. Наприклад, ви можете зробити дуже корисні речі з простором імен .NET System.DirectoryServices.

Я програміст і старший адміністратор / інтегратор. Щоб працювати там, де я займаюся, вам потрібно знати наступні речі:

• Як писати сценарії оболонки (POSIX, без башизмів), трохи Perl, трохи Python
• Basic C (Єдина специфікація UNIX)
• Як встановити ланцюжок інструментів компілятора
• Як створити бібліотеки та інші проекти OSS з джерела
• Що таке Valgrind і як його використовувати для виявлення витоків пам'яті
• Як згорнути пакети .rpm та .deb
• Поки ми цього не вимагаємо , трохи PHP і трохи LISP не зашкодить

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

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

Якщо підсумовувати, то, що добре заокруглення ніколи не зашкодить вам.

Багато, багато років тому (насправді Windows NT 3.1) я почав працювати як програміст, який спеціалізується на написанні послуг і навіть випадкових драйверів пристроїв. Це означає, що ви добре знайомите з ядром Windows. З часом я трохи набрид програмуванням і перейшов до управління мережею. Я виявив, що мій досвід програмування був неодмінно цінним знову і знову.

Справа не лише в тому, що писати сценарії VBScript відносно безболісно. Знання того, як працюють кишки Windows, і особливо, як працює IP, дуже допомагає при деталізації незвичайних проблем із сервером та мережею. Також це мислення. Програмісти звикли до контролю над документацією та версіями, і це мене жахає, щоб побачити, скільки адміністраторів Windows просто спробує щось перевірити, чи спрацьовує це, і потурбуватися про те, щоб потім розплутати безлад.

Все дуже добре, але не дуже корисна порада сказати піти та працювати програмістом десять років! Однак я думаю, що це допомогло б більшості системних адміністраторів мати певний досвід програмування на "жорсткій" мові, як C ++ або C #. А якщо у вашій організації є приручені програмісти, пийте з ними!

Джон Ренні

Погані речі трапляються, ваш код буде довше, ніж ви думаєте, що буде. Збій витончено, з корисними повідомленнями про помилки. У вас не вистачить диска, оперативної пам’яті, процесора, часу тощо.

Не будьте настільки оптимістичними, що дивно один раз у мільйонному випуску траплятиметься занадто часто у виробництві.

З усіма описами тут я не збираюся говорити, що я систематик. Але в тому, що я створив і керував паролем windows / linux-сервера, я повинен щось визнати:

• в Linux, баш сценарії обов'язково знати - якщо ви знаєте, як інтегрувати його з perl / awk / тощо, це краще. Я виявив, що багатьом завданням стало легше, використовуючи його.

• Знання програмувати на C / C ++ дуже допомагає. Іноді доводиться змінювати вихідний код GNU (якщо ви його використовуєте), щоб відповідати вашим потребам, оскільки продукт GNU не гарантує, що ви завжди будете отримувати потрібну вам допомогу вчасно - і багато разів вони написані на C / C ++.

• SQL - Все працює з базами даних
• Програмування - мова не має значення, доки ви розумієте логіку та процес, ви можете вивчити та адаптуватися до будь-якої мови.
• Як ДОКУМЕНТУВАТИ КОД і ЗМІНИ - це величезна кількість. Скільки разів ви застрягли, дивлячись на конфігурацію, намагаючись з'ясувати, чому чорт зробив хтось це, і що це вплине, якщо ми змінимо її назад. Це виходить за рамки будь-якого коду чи скрипту; це стосується, коли ви вносите зміни в налаштування брандмауера, щоб обробити ситуацію із бахромою, коли користувач X отримує електронну пошту з домену Y у вівторок вдень, коли починається дощ. І це може бути не ви, це може бути PFY, який вирішить піти вперед і зробити itand, а потім повинен зателефонувати вам о другій ранку у вашій відпустці, тому що все зламалося в жахливій формі.
• Системні мови. У Windows такі речі, як Powershell та WMI, дозволяють вашим мовам сценаріїв зв’язуватися з деякими досить потужними ресурсами і робити все на ПК. У Unix / Linux є власний набір інструментів, про які я не кваліфікований.

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

Це може здатися базовим, але я бачив безліч хлібобулочних магазинів, де люди не думають, що мають потребу в такому управлінні системою. Дуже багато місць витрачають великі $$$ на великі набори адміністративних інструментів, і, наскільки я можу сказати, 95% того, для чого вони використовують інструменти, можна було б зробити за кілька годин сценаріїв, якби хтось знав це чи знав, як це зробити Зроби це.

Я виявив, що знання сценаріїв bash, dos batch та powerhell надають системному адміністратору рамки робити практично все на будь-якій популярній системі.