Как программист, мы склонны принимать сисадминов как должное. Несколько раз, когда я был без хорошего системного администратора, я действительно ценил то, что вы, ребята, делаете. Когда мы отправляемся в среду, в которой нет сисадмина, какие слова мудрости вы можете нам предложить?
Ответы:
Я бы начал с:
<вставьте большой отказ от ответственности здесь>
Некоторые из них были сказаны ранее, но стоит повторить.
Документация:
Документ все. Если у вас его нет, установите вики-страницу под радаром, но обязательно сделайте резервную копию. Начните со сбора фактов, и однажды образуется большая картина.
Создавайте диаграммы для каждого логического блока и обновляйте их. Я не мог сосчитать, сколько раз точная карта сети или кластерная диаграмма спасли меня.
Сохраняйте журналы сборки для каждой системы, даже если это просто копирование и вставка команд для сборки.
При сборке вашей системы установите и настройте свои приложения, протестируйте их и проведите сравнительный анализ. Теперь протрите диски. Шутки в сторону. '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, они были бы моим новым лучшим другом.
Я удивлен, что ни один из 17 ответов, приведенных здесь, пока не содержит ничего о том, как обеспечить работу вашего приложения при входе в систему как обычного пользователя.
Помимо процесса установки, приложение должно работать нормально при входе в систему со стандартной учетной записью пользователя.
Это может относиться только к начинающим программистам, но я имею дело с некоторыми вещами в каждом проекте с некоторыми программистами.
«Это работает на моей машине» не является действительным утверждением. Программист несет ответственность за создание программы установки для использования на сервере или, по крайней мере, документирование каждого соединения и DLL и надстройки, которые потребуются на сервере.
(Я слышал это несколько раз, поэтому, пожалуйста, не смейтесь) Я запускаю exe на сервере со своей машины, и он работает. Но когда я запускаю его на сервере (Citrix, Terminal Server и т. Д.), Он не работает. Пожалуйста, поймите, dll, ocx и все остальное, что требуется вашей программе, где и как они зарегистрированы, и как ваша программа использует их.
Это может показаться простым, но я занимаюсь этим постоянно.
Брайан
ОК, это немного разглагольствует, но:
а) При кодировании предположите, что базовая инфраструктура может выйти из строя и не приходит от счастливой счастливой всегда на земле. Или гугл.
б) У нас, вероятно, нет ресурсов для реализации чего-либо вроде инфраструктуры, о которой вы читали, так что будьте спокойны, когда дела пойдут плохо. Вероятно, мы знаем, что нужно сделать, но по какой-то причине этого еще не произошло. Мы ваши партнеры!
c) Как сказал выше jhs, было бы очень полезно, если бы вы были знакомы с инструментами для устранения неполадок в инфраструктуре, такими как ping, traceroute (или объединение обоих - mtr), копанием и т. д. Огромные бонусные баллы за то, что вы даже знаете о Wireshark.
d) Если вы программируете компьютер, вы действительно должны знать, как он подключается к сети, а также основам, таким как возможность анализировать выходные данные ipconfig / all или ifconfig. Вы должны быть в состоянии установить ваше интернет-соединение с минимальной помощью.
В противном случае я думаю, что Эйвери в значительной степени прибил это. Разработчики, которые делают немного сисадмина, на вес золота! Но в равной степени, системные администраторы, которые понимают, как разработчики идут о вещах (включая управление версиями и т. Д.), Очень важны в наше время.
Кажется, в данный момент это происходит, я заметил больше дискуссий об отношениях dev / ops в блогах - посмотрите
Что ни одна группа или функция не «лучше», чем другая, и что ни одна из них не требует «большего мозга», чем друг друга. Я видел, как обе стороны проявляют примадонность в компании другой - вы все пытаетесь достичь одних и тех же целей - сосредоточьтесь на этих сходствах, а не на том, что вы используете разные инструменты.
Архитектор инфраструктуры, ставший программистом, возможно, захочет откатить эту транзакцию в будущем :)
Как кто-то, кто был системным администратором для разработчиков и сам разработчик, совет, данный здесь, не только золотой, но и должен быть частью документации по найму новых разработчиков для компаний во всем мире.
Что-то, что я еще не видел (пока) объяснил, так это то, что разработчики действительно должны знать продукты, которые они будут использовать для создания программ, за которые им платят. Количество случаев, когда мне приходилось объяснять и настраивать серверы Apache, установки Eclipse и Visual Studio, а также базы данных на компьютерах разработчиков, вызывает некоторое беспокойство.