Решил вот описать принципы управления серверами, к которым пришел за эти 3 года.
Итак:
принцип №1
Все конфиги лежат в VCS, я сейчас использую Git. Я думаю, в комментариях принцип не нуждается, необходимость централизованного хранения конфигов, а также хранения истории изменений с возможностью отката обсуждалась не раз.
принцип №2
Все ПО ставится только из пакетов, никаких ./configure && make && make install. Если пакета нужной версии нет в репозиториях дистрибутива - ищем готовый пакет, желательно от разработчиков, или от солидного стороннего репозитория типа dotdeb. Если пакета для ПО нет - собираем пакет сами, причем процесс сборки документируется, а все нужное для сборки кладется в VCS. Все сторонние пакеты собираются в свой репозиторий, в котором как минимум есть разделение на stable и testing. Все пакеты из testing, после проверки на стейджинге, перемещаются в stable. Таким образом, мы контролируем установленное ПО средствами дистрибутива, что сильно упрощает жизнь сисадмина.
Уже руководствуясь этими двумя принципами, мы можем без лишних усилий развернуть точную копию нужного окружения (production или staging), повторяемость которого нам гарантированна.
Но для того, чтобы разворачивать все быстро, и не полагаться на свою память, есть
принцип №3
Последовательность действия для развертывания каждого компонента системы документируется. Если не используется система управления конфигурациями - документируется в виде последовательности команд с комментариями. Сейчас я использую Ansible, и в этом случае сами taskи и playbookи Ansible являются отличной документацией. В случае использования Chef, грамотно написанные рецепты также сами по себе являются документацией.
Теперь мы можем разворачивать нужное окружение в автоматическом режиме. А еще, можно тестировать работоспособность всей системы в целом, используя любую из систем Continuous Integration, задав задание разворачивать окружение целиком, с нуля, в автоматически создаваемых для этого виртуалках.
Теперь, для полного спокойствия в случае падения метеорита на наш production, нам нужен
принцип №4
Для всех данных надо выполнять резервное копирование. Причем нужна и репликация (для failover), и создание резервной копии, причем с возможностью отката назад по времени, и создание offsite-копии на случай форс-мажора. Я неоднократно выслушивал мнение, что репликация базы данных отлично заменяет резервное копирование. На такое заявление я отвечаю предложением подумать, что будет с репликой в случае выполнение на master-сервере команды удаления либо изменения наших данных из-за программной ошибки, либо из-за действий злоумышленника.
принцип №4а
Резервные копии надо тестировать! Я даже вынес этот тезис в отдельный пункт, поскольку именно про него обычно и забывают, и оказываются в итоге с неработоспособным бекапом.
Выполняя эти 4 принципа, мы можем быть уверены, что даже в случае падения метеорита на наш production, мы сможем его восстановить без нервов, и в разумные минимальные сроки.
А чтобы не порушить случайно чего-нибудь, есть
принцип №5
Руками на production ничего делаться не должно. Все действия выполняются только с помощью системы управления конфигурациями (Chef, Ansible, Puppet и т.п.), причем обязательно тестируются на staging-серверах. Это дает нам уверенность в том, что мы не опечатаемся, набирая в команду в 25й раз, и вообще спасает от повторения одних и тех же действий на каждом сервере. А еще это дает нам окружение, в котором все сервера находятся в одинаковом, известном заранее состоянии, все компоненты для получения которого у нас есть в VCS.
принцип №6
Если что-то не мониторится, то этого не существует. Если мы не осуществляем мониторинг какого-либо сервиса, то мы не можем быть никогда уверены, что этот сервис в данный момент времени вообще функционирует. Поэтому, все важные сервисы должны быть под наблюдением. Как и сам сервис мониторинга. И, конечно, мониторинг тоже надо тестировать.
Естественно, есть и другие принципы, но это - основа основ, благодаря которой я спокойно сплю по ночам, и уверен, что любое обновление на боевых серверах пройдет гладко, а даже если и нет - всегда можно откатиться к предыдущему, работоспособному состоянию.