Какие вещи сисадмина должен знать каждый программист?

Как программист, мы склонны принимать сисадминов как должное. Несколько раз, когда я был без хорошего системного администратора, я действительно ценил то, что вы, ребята, делаете. Когда мы отправляемся в среду, в которой нет сисадмина, какие слова мудрости вы можете нам предложить?

Я бы начал с:

1. Всегда имейте какую-нибудь резервную систему. Даже лучше, если у него есть история.
2. Рассмотрим отдельные точки отказа и как с ними справиться, если они потерпят неудачу.
3. В зависимости от количества задействованных компьютеров, поиск какого-либо способа создания и создания стандартного образа на разных компьютерах облегчит жизнь всем - никакое «это не работает на моем», потому что у них есть такая и такая программа, которая обычно не устанавливается.
4. Документ все, если только потому , что вы будете забывать , как установить что - нибудь.
5. Будьте в курсе обновлений безопасности.

<вставьте большой отказ от ответственности здесь>

Некоторые из них были сказаны ранее, но стоит повторить.

Документация:

• Документ все. Если у вас его нет, установите вики-страницу под радаром, но обязательно сделайте резервную копию. Начните со сбора фактов, и однажды образуется большая картина.

• Создавайте диаграммы для каждого логического блока и обновляйте их. Я не мог сосчитать, сколько раз точная карта сети или кластерная диаграмма спасли меня.

• Сохраняйте журналы сборки для каждой системы, даже если это просто копирование и вставка команд для сборки.

• При сборке вашей системы установите и настройте свои приложения, протестируйте их и проведите сравнительный анализ. Теперь протрите диски. Шутки в сторону. 'dd' - первый мегабайт на передней панели дисков, иначе он не сможет загрузиться. Время идет: докажите, что ваша документация может восстановить ее с нуля (или, что еще лучше, докажите, что ваш коллега может сделать это только с вашей документацией). Это составит половину вашего плана аварийного восстановления.

• Теперь у вас есть первая половина вашего плана аварийного восстановления, запишите остальные; как вернуть состояние вашего приложения (восстановить файлы с ленты, перезагрузить базы данных из дампов), сведения о поставщике / поддержке, требования к сети, как и где получить замену оборудования - все, что вы можете себе представить, поможет восстановить вашу систему.

Автоматизация:

• Автоматизируйте столько, сколько сможете. Если вам нужно что-то сделать три раза, убедитесь, что вторая часть потрачена на разработку вашей автоматизации, а третья полностью автоматизирована. Если вы не можете автоматизировать это, запишите это. Есть комплекты автоматизации - посмотрите, сможете ли вы заставить их работать на вас.

Мониторинг:

• Прикладные приборы из чистого золота. Возможность наблюдать за транзакциями, проходящими через систему, значительно упрощает отладку и устранение неполадок.

• Создавайте сквозные тесты, которые доказывают не только то, что приложение живое, но и действительно выполняет то, что должно. Очки ваши, если их можно подключить к системе мониторинга для целей оповещения. Это служит двойной обязанности; Помимо проверки работоспособности приложения, оно значительно упрощает модернизацию системы (мониторинг системных отчетов зеленый, обновление сработало, время идти домой).

• Оценивайте, отслеживайте и собирайте метрики для всего, что для этого необходимо. Тесты указывают, когда ожидать, что что-то испустит волшебный дым. Мониторинг говорит вам, когда он имеет. Метрики и статистика облегчают получение нового комплекта (со свежим волшебным дымом) через управление.

• Если у вас нет системы мониторинга, внедрите ее. Бонусные баллы, если вы действительно включите в него вышеописанные сквозные тесты.

Безопасность:

• «chmod 777» (он же предоставляет все права доступа) никогда не является решением проблемы.

• Подпишитесь на принцип «наименьшего бита»; если он не установлен, скопирован или иным образом находится на диске, он не может быть скомпрометирован. Установка «кухонной раковины» ОС и программного обеспечения может облегчить жизнь на этапе сборки, но в конечном итоге вы заплатите за это в будущем.

• Знайте, для чего предназначен каждый открытый порт на сервере. Регулярно проверяйте их, чтобы убедиться, что новые не появляются.

• Не пытайтесь очистить скомпрометированный сервер; это должно быть восстановлено с нуля. Перестройте на резервный сервер со свежескачанными носителями, восстановив только данные из резервных копий (так как двоичные файлы могут быть скомпрометированы), или клонируйте взломанный хост в какое-то изолированное место для анализа, чтобы вы могли восстановить его с помощью того же набора. Вокруг этого существует целый правовой кошмар, так что ошибайтесь в сторону сохранения на тот случай, если вам нужно искать законные пути. (Примечание: IANAL).

Оборудование:

• Никогда не предполагайте, что что-то сделает то, что написано на коробке. Докажите, что он делает то, что вам нужно, на случай, если это не так. Вы обнаружите, что говорите «это почти работает» чаще, чем вы ожидаете.

• Не экономьте на удаленном управлении оборудованием. Последовательные консоли и управление освещением следует считать обязательными. Бонусные баллы за дистанционно управляемые удлинители питания в те моменты, когда у вас нет выбора.

(Кроме того, есть два способа решения проблемы в 3 часа ночи, один из которых заключается в том, чтобы быть тёплым, работать на ноутбуке через VPN в вашей пижаме, другой - в толстой куртке и подъезжать к центру обработки данных / офису. Я знаю, какой предпочитают.)

Управление проектом:

• Вовлеките людей, которые будут поддерживать систему с первого дня жизненного цикла проекта. Время выполнения заказов и время на подготовку могут и будут удивлять, и нет никаких сомнений в том, что они будут (должны?) Иметь стандарты или требования, которые станут зависимостями проекта.

• Документация является частью проекта. У вас никогда не будет времени, чтобы написать все это после того, как проект будет закрыт, и система перейдет на техническое обслуживание, поэтому убедитесь, что это включено в график в начале работы.

• Внедрите запланированное устаревание в проект с первого дня и начните цикл обновления за шесть месяцев до дня выключения, указанного вами в проектной документации.

Серверы имеют определенный срок службы, когда они пригодны для использования в производстве. Конец этого срока службы обычно определяется как каждый раз, когда поставщик начинает взимать больше за ежегодное обслуживание, чем это будет стоить обновить комплект, или около трех лет, в зависимости от того, что меньше. По истечении этого времени они отлично подходят для сред разработки / тестирования, но вы не должны полагаться на них для ведения бизнеса. Пересмотр среды за 2 1/2 года дает вам достаточно времени, чтобы перепрыгнуть через необходимые управленческие и финансовые операции для заказа нового комплекта и осуществить плавную миграцию, прежде чем отправлять старый комплект крупному поставщику в небе.

Разработка:

• Убедитесь, что ваши разработки и системы постановки напоминают производство. ВМ или другие методы виртуализации (зоны, LDOM, vservers) упрощают создание клонов «в реальном мире, в каждом смысле, но производительности».

Резервные копии

• Данные, которые вы не сохраняете, - это данные, которые вам не нужны. Это неизменный закон. Убедитесь, что ваша реальность соответствует этому.

• Резервные копии сложнее, чем они выглядят; некоторые файлы будут открыты или заблокированы, в то время как другие должны быть приостановлены, чтобы иметь хоть какую-то надежду на восстановление, и все эти проблемы необходимо решить. В некоторых пакетах резервного копирования есть агенты или другие методы для работы с открытыми / заблокированными файлами, в других - нет. Сброс баз данных на диск и их резервное копирование считается одной из форм «успокоения», но это не единственный метод.

• Резервные копии бесполезны, если они не проверены. Каждые несколько месяцев вынимайте случайную ленту из архивов, убедитесь, что на ней действительно есть данные, и что данные согласованы.

И, самое главное...

Выберите режимы отказа, или Мерфи будет ... и Мерфи не работает по вашему расписанию.

Проектируйте для отказа, документируйте разработанные слабые места каждой системы, что вызывает их и как восстановить. Это будет иметь значение, когда что-то пойдет не так.

Не думай, что это легко. Я знаю многих программистов, которые думают, что только потому, что они могут настроить IIS или Apache на своем устройстве для разработки, они могут запустить веб-ферму. Поймите, что включает в себя работа, и проведите исследование и планирование, а не просто подумайте, что работа системного администратора - это простая вещь, которую вы можете сделать за 10 минут, чтобы развернуть свое приложение.

• Поймите, что, к лучшему или к худшему, многие серверы и / или сетевое оборудование, как правило, очень похожи на детей из второй семьи. Это их дети. Они ухаживают за ними, помогают им, когда они болеют, и бдительно следят за их проблемами. Так не должно быть, но спустя много лет, это часто так . Помните об этом, когда будете сообщать им о своих опасениях по поводу того, что оборудование не работает должным образом или не стоит ожидать. И если вы получите ответ, которого вы не понимаете, попробуйте отфильтровать его через это мировоззрение.
• Будьте в хороших рабочих условиях. Звучит сырно, но на вес золота. Когда-нибудь вам понадобится особая услуга. И однажды этот сисадмин будет рад сделать все возможное, чтобы сделать жизнь немного проще для вас, только в этот раз.
• Эти рабочие отношения идут в обе стороны. Если системный администратор очень занят, и вы могли бы немного облегчить жизнь, написав небольшой скрипт или программу, сделайте это! Они оценят это больше, чем вы знаете.
• Будь очень ясным. «Это отстой» не так ясно, как «наличие прерывистого сетевого подключения немного раздражает, есть ли шанс, что вы можете посмотреть на это?»
• Если вы думаете, что ваше приложение будет масштабироваться, спросите администратора, прежде чем предположить, что это произойдет. Они могут «увидеть» что-то, чего вы не знаете, или узнать что-то об ограничениях производительности оборудования, на котором вы собираетесь развернуть.
• Если ваше приложение нуждается в настройке, но оно не является проблемой кода, спросите, как работают серверы. Сисадмины заботятся о своих машинах с любовью и не довольны, когда они «болеют» или «плохо себя ведут». Хорошая просьба перевернет больную машину (или отремонтирует / заменит).
• (как упомянуто в другом месте) документируйте настройки, которые вы используете, и почему вы их используете. Просто «установить флажок X» или «раскомментировать строку конфигурации файла Y» не поможет. Вы можете установить опцию, которая удаляет все ваши данные при следующей перезагрузке для всего, что вы знаете.
• Если у вас нет времени документировать настройки на бумаге, попробуйте документировать их в системе, если это возможно. С конфигурационными файлами, то это должно быть почти стандартная практика - все настройки изменение должно быть штамп даты, с инициалами, ожидаемый эффект от этой установки, и причина , почему оно было изменено (см перед точкой пули). Эта небольшая привычка спасла мой бекон не раз во время хруста. "Почему мы это сделали?" «Потому что мы предписали политику X, а параметр Y дает нам поведение, необходимое для политики X».
• Пиво. Или кола. Или даже Вода. Напитки всегда приветствуются. Быть сисадмином - это жаждущая работа.

Безопасность не запоздалая мысль. В то время как взломанное приложение может заставить программиста выглядеть некомпетентным, это (по крайней мере) потерянные выходные, потраченные на проверку, очистку и / или восстановление из резервных копий системного администратора.

В связи с этим, не рассматривайте резервные копии как контроль версий. Они предназначены для аварийного восстановления и не предназначены для восстановления вашего кода, потому что вы забыли, что изменили.

И перестаньте слепо обвинять Обновления Windows в нарушении вашего кода. Мне все равно, что это сработало раньше, скажите мне, почему это не работает сейчас - тогда мы сможем увидеть, чья это вина.

Как отлаживать проблемы с сетью и наблюдать за тем, как ваша программа работает с помощью инструментов sysadmin. Как программист, который начал заниматься системным администрированием, я поражен тем, насколько бессильными становятся многие программисты, когда работа в сети «просто прекращается».

• Wireshark , чтобы посмотреть, как ваш код работает в режиме черного ящика, пакет за пакетом
• Инструменты для подключения напрямую к сетевым сервисам:
  • Telnet, netcat или socat для простых соединений по TCP или UDP
  • OpenSSL для того же самого с шифрованием (подсказка: попробуйте openssl s_client -connect target-host:portкогда-нибудь), для ручного подключения к сетевым сервисам
• dig (в пакете BIND 9) для разрешения отладки имен
• Возможность определить, какая часть сетевого стека вышла из строя, исходя из времени и других характеристик неисправного соединения
• Возможно HTTPFox и / или Firebug

Знать, как решать проблемы.

Это очень легко преодолеть (например, ваша сеть теряет связь с базой данных). Это может быть ошибка сети, но у вас должны быть журналы приложений с ошибками, которые, используя Google или SO, могут выявить проблему в конфигурации приложения.

Каждый любит обвинять аппаратное обеспечение, ОС или сеть, поэтому, если вы будете немного больше проявлять должную осмотрительность, вы сделаете сисадмина счастливым человеком. Потому что, если не что иное, вы можете указать им конкретное направление относительно того, что может быть не так (в отличие от того, чтобы сказать «ваша сеть отстой» или что-то такое же полезное).

Документируйте все, что можете. Не могу сказать, сколько раз последний системный администратор думал, что было бы мило не документировать что-либо для «обеспечения безопасности работы» или кто-то просто хотел войти и выйти. Как программист должен оставлять хорошие комментарии, так и системные администраторы должны документировать. Схема топологии тоже подойдет.

План б.

Всегда имейте в виду план аварийного восстановления при проектировании и разработке решения. Распознавать отдельные точки отказа, которые могут привести к отключению.

Документация: не нужно сходить с ума, но как работает приложение, диаграмма, показывающая, как подходят биты, и способы тестирования каждого компонента, когда все идет не так. Образец данных и вывод это хорошо.

Требования: на какие модули он опирается? Версии? ОПЕРАЦИОННЫЕ СИСТЕМЫ?

Мониторинг: в идеале разработчики должны включать мониторинг информации и тесты с приложением.

Кстати, об упаковке, УПАКОВКЕ! Нет ничего хуже, чем «развертывание», которое означает, что нужно проверить новую версию файла из VCS и скопировать ее на несколько серверов. Слишком часто программисты не ценят сложность развертывания программного обеспечения: есть причины, по которым пакетное программное обеспечение с версиями составляет основу большинства операционных систем.

Если бы разработчик пришел ко мне с RPM, который был установлен впервые с краткой, исчерпывающей документацией и некоторыми тестами Nagios, они были бы моим новым лучшим другом.

Я удивлен, что ни один из 17 ответов, приведенных здесь, пока не содержит ничего о том, как обеспечить работу вашего приложения при входе в систему как обычного пользователя.

Помимо процесса установки, приложение должно работать нормально при входе в систему со стандартной учетной записью пользователя.

Резервное копирование Резервное копирование .... Проверьте резервную копию .... Всегда будьте готовы к откату

Это может относиться только к начинающим программистам, но я имею дело с некоторыми вещами в каждом проекте с некоторыми программистами.

1. «Это работает на моей машине» не является действительным утверждением. Программист несет ответственность за создание программы установки для использования на сервере или, по крайней мере, документирование каждого соединения и DLL и надстройки, которые потребуются на сервере.

2. (Я слышал это несколько раз, поэтому, пожалуйста, не смейтесь) Я запускаю exe на сервере со своей машины, и он работает. Но когда я запускаю его на сервере (Citrix, Terminal Server и т. Д.), Он не работает. Пожалуйста, поймите, dll, ocx и все остальное, что требуется вашей программе, где и как они зарегистрированы, и как ваша программа использует их.

Это может показаться простым, но я занимаюсь этим постоянно.

Брайан

• поговорите со своим администратором официально и неофициально о том, что вы делаете. Они, как правило, заинтересованы и могут выразить возможные последствия для производства на раннем этапе. Вы не должны соглашаться, но это помогает определить проблемные места.
• Нет, вы не можете иметь весь сервер для себя ... Если вам нужно, это политическое решение, независимо от того, насколько оно технически обосновано. Если вы хотите работать в политике, идти вперед.
• Производственное оборудование часто выглядит иначе, чем ваш сервер разработки, и даже внутри ферм спецификации на машины отличаются.
• Узнайте, как настроено производство, потому что вы, вероятно, не сможете воспроизвести его на своем рабочем столе, так как это поможет вам сделать неверные предположения.
• То, что вы можете кэшировать данные в памяти, вовсе не означает, что вам следует сначала подождать узкого места (в модульном тестировании или тестировании производительности перед началом производства).
• если вы помещаете данные в базу данных, подумайте, как можно разбить данные на данные только для чтения (которые можно масштабировать по горизонтали) и данные для чтения и записи (которые обычно масштабируются только по вертикали).
• если вы помещаете данные в базу данных, должна ли быть действительно СУБД? Существуют и другие системы пар ключ-значение, которые лучше масштабируются (netcache).
• Не думаю, что AJAX - это универсальное решение, оно выглядит круто, но оно ограничивает возможности мониторинга и автоматизации. Я не говорю, не используйте его, просто подумайте дважды.

ОК, это немного разглагольствует, но:

а) При кодировании предположите, что базовая инфраструктура может выйти из строя и не приходит от счастливой счастливой всегда на земле. Или гугл.

б) У нас, вероятно, нет ресурсов для реализации чего-либо вроде инфраструктуры, о которой вы читали, так что будьте спокойны, когда дела пойдут плохо. Вероятно, мы знаем, что нужно сделать, но по какой-то причине этого еще не произошло. Мы ваши партнеры!

c) Как сказал выше jhs, было бы очень полезно, если бы вы были знакомы с инструментами для устранения неполадок в инфраструктуре, такими как ping, traceroute (или объединение обоих - mtr), копанием и т. д. Огромные бонусные баллы за то, что вы даже знаете о Wireshark.

d) Если вы программируете компьютер, вы действительно должны знать, как он подключается к сети, а также основам, таким как возможность анализировать выходные данные ipconfig / all или ifconfig. Вы должны быть в состоянии установить ваше интернет-соединение с минимальной помощью.

В противном случае я думаю, что Эйвери в значительной степени прибил это. Разработчики, которые делают немного сисадмина, на вес золота! Но в равной степени, системные администраторы, которые понимают, как разработчики идут о вещах (включая управление версиями и т. Д.), Очень важны в наше время.

Кажется, в данный момент это происходит, я заметил больше дискуссий об отношениях dev / ops в блогах - посмотрите

Сохранение Твиттера

Перегородки и Война

Первый тест в операциях

Что ни одна группа или функция не «лучше», чем другая, и что ни одна из них не требует «большего мозга», чем друг друга. Я видел, как обе стороны проявляют примадонность в компании другой - вы все пытаетесь достичь одних и тех же целей - сосредоточьтесь на этих сходствах, а не на том, что вы используете разные инструменты.

Архитектор инфраструктуры, ставший программистом, возможно, захочет откатить эту транзакцию в будущем :)

1. Поговорите друг с другом, рано и часто. Просмотрите проекты с парнями, которые будут управлять инфраструктурой, на которой будет развернуто ваше приложение (если вы знаете, кто это будет).
2. Нулевая потеря данных возможна, но ответственность за это несут разработчики и системные администраторы. Снова, общение друг с другом может помочь здесь.
3. Сотрудники вашей инфраструктуры должны были принять участие в определении нефункциональных требований.
4. Организовать пиво (когда работа сделана) и пиццу (пока мы работаем). Каким-то образом присутствие такого рода продуктов питания влияет на нашу способность заставить наши милые маленькие 32 процессорные коробки делать то, что вы от них хотите :)

Как кто-то, кто был системным администратором для разработчиков и сам разработчик, совет, данный здесь, не только золотой, но и должен быть частью документации по найму новых разработчиков для компаний во всем мире.

Что-то, что я еще не видел (пока) объяснил, так это то, что разработчики действительно должны знать продукты, которые они будут использовать для создания программ, за которые им платят. Количество случаев, когда мне приходилось объяснять и настраивать серверы Apache, установки Eclipse и Visual Studio, а также базы данных на компьютерах разработчиков, вызывает некоторое беспокойство.