7 очевидных правил безопасного системного администрирования физических серверов

    Данные правила, как говорится, «написаны кровью». Возможно, кому-то они помогут сохранить немного (много) жизни и нервов.

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




    1. Подготовь план отката внесенных изменений.

    2. Убедись, что знаешь рутовый пароль к серверу. Если не знаешь, установи новый. Проверь, что можешь под этим паролем залогиниться.

    3. KVM заказать ДО проведения работ. Работы не начинать, пока не залогинишься на консоль KVM под рутом.

    4. После того, как залогинился на сервер проверь, что залогинился КУДА НУЖНО. Как минимум, запусти htop, ifconfig, проверь содержимое /var/www

    5. Сделай бэкап всех файлов, которые собираешься изменять.

    6. Если на сервере есть критичные сервисы (простой которых недопустим) — сделай бэкап всех их данных, есть вероятность, что ты видишь этот сервер в последний раз. Проверь, что данные из этого бэкапа восстанавливаются (например, на виртуалке).

    7. Помни, что из консоли все сервера выглядят одинаково.

    А какие правила для себя вы установили в аналогичных ситуациях? Чем можете поделиться?
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 70
    • +4
      На одном из серверов у меня установлен вот такой забавный баннер и $PS1 показывает, где и под каким пользователем я нахожусь: ascii.io/a/1166. Но на других серверах также сделать всё руки не доходят.
      • 0
        Мы тоже «раскрашиваем» сервера (вот так habrahabr.ru/post/107038/), но и это помогает не всегда :)
        • 0
          Не поделитесь рецептиком случайно? Спасибо заранее. :)
          • +1
            gist.github.com/3742409

            Собственно, .bashrc давно где-то подсмотрел, немного адаптировав под свои нужды, баннер сделал через figlet :)
            • 0
              Благодарствую, поковыряем. :)
          • 0
            sudo su? sudo -i
            • 0
              Знаю, просто как-то уже привык, да и набирать sudo su удобнее.
          • +12
            0. Помнить законы Мерфи. Всё, что может упасть, непременно упадет. Обязательно исходить из худшего при планировании работ.
            8. Заранее согласовать maintenance window и убедиться, что отключение сервера не вызовет катастрофы у коллег. Возможно, имеет смысл заранее остановить другие системы, которым может поплохеть от внезапного исчезновения пациента из сети.
            9. Постараться организовать инфраструктуру так, чтобы отключение одного сервера не вызывало отказа всего сервиса.
            10. Если п.9 выполнен, то перед любыми мало-мальски опасными действиями следует штатно вывести сервер из экспуатации. Это легко реализовать так, чтобы ни один пользователь и ни одна сторонняя система этого не заметили. А потом пусть он хоть сутки лежит — в худшем случае снижаются производительность сервиса и степень резервированности.
            • +1
              11. Снижая степень резервированности (см. п. 10), помните законы Мерфи (см. п. 0).
            • 0
              А почему именно физических?
              Моё мнение, что это в полной мере относится и к виртуальным машинам, в общем, разве что исключая некоторые ньюансы.
              • 0
                Вы правы. Первоначально в заголовке было и про виртуалки. В процессе редактирования подсократил.
                Но с виртуалками чуть проще — часто к ним есть прямой «терминальный» доступ.
                • 0
                  Там кстати хватает ньюансов, например хост-машина, обращающаяся за авторизацией пользователя на виртуалку — DC, которая живёт на ней, которая внезапно умерла — проходили, мозги админу промывали…

                  Вообще еще вот сильно хорошо и правильно это документирование — L1,L2,L3, L>4…
                  Что, где, почём, как настраивалось…
                  • +5
                    например хост-машина, обращающаяся за авторизацией пользователя на виртуалку, которая живёт на ней, которая внезапно умерла
                    OH, SHI--
              • +5
                0) Работать в screen.
                1) Если вносятся изменения в ssh-server, то заранее поднять ssh-server на альтернативном порту. При разрыве соединения поможет вести себя адекватно :)
                • +1
                  еще можно по таймауту сделать рестарт сервиса/сервера, например
                  • +3
                    Если конфиг испорчен — не поможет. А вообще да, job/cron на ближайшее будущее со скриптом отката — хорошая практика.
                    • +3
                      по таймауту восстановить конфиг из бекапа и рестар сервиса/сервера еще туда же.
                    • +1
                      тут главное не забыть его потом отключить ;)
                • +6
                  Сочуствую вашей работе, ей богу)
                  У меня так:
                  1. сделай в тестинге
                  2. сделай на паре машин продакшна.
                  3. сделай на первой половине кластера
                  4. сделай на оставшемся кластере.

                  • 0
                    Как минимум, для этого нужно, чтобы все четыре перечисленные тобой понятия имели смысл (:
                    • 0
                      Ы. Мы тут все соберемся так скоро)

                      Я думаю, для тех, у кого есть что-то вроде кластера (или хотя бы 1-2 стадии тестинга) — имеет смысл, даже если слова непонятны. А админам, у кого dev == testing == production, можно кол на голове тесать — не поможет. Впрочем, для девелоперов тоже актуально.
                  • +3
                    Раскрашено приветствие сервера в .bashrc. Помогает в частности то, что хостнэйм у машин разный, и он ярко выделен.
                    • 0
                      Еще помогает не наломать дров, да и вообще экономит время, на машинах с разных хостерских площадок — у каждого хостера свой цвет.
                    • –1
                      Правило 0: сделай снимок виртуальной машины.
                      • 0
                        я бы сказал — установи виртуалку, накати гостевые дополнения, обнови по максимуму, слделай снапшот, накати нужный софт, в процессе документируй что где и как, после чего еще один снапшот, после чего шатдаун и тест включения на другом физическом сервере виртуализации.
                        Что, в общем не мешает бекапу
                        • 0
                          Ну, я исхожу из того, что мы обновляем что-то, а не ставим с нуля.
                      • +5
                        0. Проведи работы на тестовом сервере и подожди сутки;
                        7. Веди отдельный лог команд во время проведения работ, чтобы потом судорожно не рыться в history;
                        8. Работать надо в здравом уме и светлом разуме, а не работать день-вечер и ночью накатвать обновления;
                        9. Разноси аппаратные, состемные и прикладные обновления как минимум на сутки;
                        • +4
                          Не выполняй несколько критичных, требующих внимательности работ параллельно. Закончил с одной — приступай к другой.
                          • +1
                            Добавлю еще — если не выспался или там отвлекают — лучше вообще сделать logout на сервере. Пару раз в конце дня, сонный и с задуренной головой, едва-едва не выключил удаленный сервер. В принципе у меня в каждом сервере стоит своя kvm, но все равно минут 5-10 простоя критичны, и обидны, когда сделаны из-за глупости. После этого кстати и стал я раскрашивать hostname у серверов — во первых, яркий цвет сразу в глаза бросается, во-вторых при выводе больших сообщений на экран четко видна разница к примеру между двумя выводами сообщений.

                            От себя еще добавлю пару моментов. К сожалению, screen-ом я не пользуюсь по ряду причин, но пользуюсь tmux, он тоже умеет функции screen. По вечерам и в пятницу никаких обновлений, мне дороги выходные. То есть обновления лучше накатить в районе полуночи, чтобы чуть что — была ночь времени. Обязательно бэкап всех конфигов и прочих важных файлов.
                            • +1
                              Ну тогда ещё одно правило, убрать из пуска shutdown\reboot
                              • 0
                                А из «безопасного извлечения» — сетевуху. А то один раз коллеги таким вот образом умудрились потерять сервер.
                          • +1
                            x. Сложи все сервисы на этом сервере за несколько десятков минут до начала работ. В случае, если окажется, что этот сервер нес что-то критическое, о чем забыли — ты сможешь мгновенно это что-то запустить и отложить maintenance.
                            • +1
                              А потом объясняйся перед руководством, службой мониторинга, финансами, почему начал работы невовремя и все занервничали…
                              • 0
                                не всегда. клгда-то у знакомого тоже отвалился сервер, а на нём оказалась достаточно критичная забытая до полной автоматизации штука, нужная раз в день… ночью она, понятное дело не отработала…
                              • 0
                                У нас еще есть сервер, на котором поднята загрузка по сети. В случае факапа, пострадавший сервер пускается в перезагрузку, загружается по сети, на него можно зайти по ssh, примонтировать разделы и откатить изменения.
                                • 0
                                  я выше описал: бекап конфигов и если что-то пошло не так в планировщике восстановление конфигов из бекапов и рестарт нужных сервисов/сервера.
                                  загрузка по сети — да, тоже, в общем позитивно.
                                • 0
                                  Про 7 пункт помню, как человек с которым вместе работаем выполнил на удалённом сервере sudo halt, т.к. перепутал с рабочим ПК.
                                  • 0
                                    Ещё есть кошмарный прикол на эту тему. Большие мониторы, переключение активного окна курсором мыши (а не кликом). Периодически такое переключение залипает. В итоге админы тащат мышь, тянут её в консоль и пишут reboot. А потом радостно наблюдают сообщение вида system will be rebooted now в соседней консоли)

                                    Себя в этом месте полечил двумя моментами:
                                    1) ноут никогда не выключать, а усыплять.
                                    2) если нужен ребут локальной машине (ноуту) — делать из ctrl-alt-f1 или по кнопке.
                                  • +3
                                    Как завещал великий Админ — «Бэкап, бэкап и еще раз бэкап».
                                    • +3
                                      1) У меня в планах написать программу, которая сканирует сеть nmap'ом и запоминает открытые порты, с тем чтобы после изменений/перезагрузок проверить не потерялось ли что-то (актуально при перезагрузки сервера виртуализации с кучей виртуалок).

                                      2) Наверно стоит netstat перед изменением запускать и сравнивать после изменений — это всё к тому, что некоторые сервисы имеют тенденцию быть запущены вручную год назад, про них все забыли, и в автозагрузку не включили.

                                      3) перед изменениями стоит сделать перезагрузку без внесения каких либо изменений, чтобы убедиться что сервер вообще рабочий. Некоторые ошибки незаметны во время работы, но проявляются при загрузке — например такое бывает у grub при переходе от 1 к 2-й версии, или в некоторых дистрибутивах-сборках типа turnkey, при смене ядра.

                                      4) посмотреть что в логах пишется, отфильтровав сообщения мусорящих сервисов типо cron, postfix

                                      5) убедиться что на сервере достаточно свободного места

                                      6) посмотреть насчёт работающих сессий screen
                                      • +15
                                        Не правило, но примета: настраиваешь firewall на удаленном сервере — к дороге.
                                        • 0
                                          Как выше верно подметили, cron с откатом конфига может спасти от дальней дороги :)
                                          • +1
                                            Во FreeBSD есть скрипт /usr/share/examples/ipfw/change_rules.sh который помогает избежать данной ситуации, там если отвалился shell, то происходит возврат правил обратно.
                                            Для iptables возможно тоже есть подобное, если кто знает — подскажите, пожалуйста.
                                            • 0
                                              выше уже несколько раз писали про крон
                                              пишем скрипт с дефолтными правилами + обязательно с открытым портом ссх
                                              прописываем скрипт в крон, начинаем работать с фаером
                                              закончили работать, проверили, убрали скрипт
                                              еще главное не забыть убрать)

                                              лет 10 назад ночью наступил на эту «мину», благо правила применял в живую, а не писал в конфиг
                                              попросил сотрудников ткнуть ресет сервера по приходу в офис:)
                                          • +2
                                            Прочёл что большинство техногенных катастроф были в понедельник. Люди за субботу, воскресенье настроят планов и с утра понедельника начинают слишком ретиво всё внедрять.
                                            Взял за правило, в понедельник ничего серьёзного не внедряется, только текущие задачи.
                                            К вторнику обычно все затеи критически переосмысливаются.
                                            То есть на критические изменения в понедельник и в пятницу — табу!
                                            • 0
                                              Понедельник день тяжелый. Наученный горьким опытом я все делаю в выходные. Желательно в субботу с утра, чтобы был запас времени на устранение внезапно случившегося факапа.
                                              Основное правило — забэкапь всё, с чем будешь работать. При работе с базами (наша весит 600гб и ее простой недопустим в принципе) всегда проверяю возможность восстановления из бэкапа. Заранее минимум день-два предупреждаю всех пользователей о недоступности сервиса, чтобы не сорвать какую-нибудь отчетность у бухгалтерии или другого департамента.
                                              Как уже писали, никогда не вношу изменений если буду отсутствовать в офисе на следующий день. Обновления стараюсь ставить только критичные, в этом вопросе руководствуюсь пословицей «не было печали, апдейтов накачали».
                                              • 0
                                                ИМХО, в субботу с утра не самый хороший вариант.
                                                1. Если что-то пошло не так, то возможно придётся поднимать/искать других адимнов. В субботу это сделать сложнее, чем в середине недели, так как админы могут уехать на дачу, напиться и что-то подобное.
                                                2. В субботу обычно не полная нагрузка на системы, как в рабочие дни. Тяжело будет понять, всё ли работает как надо с меньшей нагрузкой.
                                                • 0
                                                  Я начальник отдела, по этому полагаюсь только на себя ))
                                                  • 0
                                                    1. Хорошо, когда админы работают посменно 7 дней в неделю.
                                                    2. В выходные не всегда падение, есть проекты, где наоборот значительный рост.
                                              • +1
                                                Не забываем одно из главных правил: не крути две ручки сразу. То есть: сделал одно изменение — проверь последствия. Только потом меняй что-то еще.
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                  • 0
                                                    Некоторые вещи таки делаются исключительно в небизнес тайм и требуют большого промежутка времени — например очень толстые бекапы, когда ресурс должен быть полностью отключен.
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                      • 0
                                                        Ну вот у нас есть конкретный такой «бизнес», где единственный продолжительный даунтайм — новогодние праздники.
                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                          • 0
                                                            Сверхурочными, очевидно. Чего тут скрывать.
                                                            • 0
                                                              Не всегда толковая мотивация… особенно в НГ
                                                              • 0
                                                                А не надо ничего в сам НГ делать, есть же еще каникулы.
                                                              • 0
                                                                Хорошие сверхурочные, видимо
                                                                • 0
                                                                  Осталось понять сопоставимы ли эти «хорошие сверхурочные» и срочность/объемы необходимых работ… а то и «хорошие сверхурочные» знаете ли :)
                                                    • +1
                                                      Правила правилами, мы их все мастера составлять :) Видно-же, что грабельки-то затоптанные…
                                                      Судя по «своим» и своему опыту, кажется мне, что таки только сафари по долине Серенгети, пешком, голышом, со свежей говяжей вырезкой намертво прилепленной к спине «экскурсия через семь кругов ада» вызванная факапом собственного производства, включает тот самый режим осторожности, спланированности и обдуманности действий, и лишь в этом случае имеют практическую пользу такие вот советы.
                                                      Мы вот взяли за практику новичкам стресс-тест устраивать (и весело и полезно, главное потом не спалиться, что факап подстроен, ну и естественно быть в боеготовности все сделать самим если пациент облажается)
                                                      • +1
                                                        lvm --snapshot /dev/vg/root -L 50G -n tmp-root

                                                        после этого правка конфига grub: default saved, в пункте 0 — savedefault 1, а пункт 1 — это старый, рабочий конфиг со старым, рабочим томом root

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

                                                        Если через неделю, скажем, всё ОК — можно сносить снэпшот.
                                                        • 0
                                                          Хорошая подстраховка. Но никак руки не дойдут этот вариант оттестировать.
                                                        • 0
                                                          Правила безопасности всегда составляются индивидуально. Обжигаются когда их было недостаточно, замедляют время работы когда они избыточны. Поэтому всегда разговор об идеальной схеме работы заканчивается решением руководствоваться только здравым смыслом.

                                                          Аппроксимируя мысль в целом можно сказать, что основная идея безопасной схемы — продуманная архитектура. Когда весь сервис будет доступен в полном или ограниченном режиме всегда. И если все таки не будет доступен, то сможет сказать о проблемах сам или с помощью наблюдающих.
                                                          • 0
                                                            А что такого плохого, если сервер не поднимется? Ну попросить инженеров перезагрузить, ну в крайнем случае утром в понедельник переустановить. (хорошо, когда облако).
                                                            • 0
                                                              Если кратко, то «время — деньги».
                                                              • 0
                                                                Время человека или время машины?

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

                                                                ЗЫ Я ещё раз намекаю, что в хорошей архитектуре выключение сервера не влияет на функциональность системы.
                                                            • 0
                                                              В первую очередь нужно прикрыть собственную жопу необходимым количеством служебок. В идеале — получить от руководства приказ на выполнение такого рода работ, в ответ на который написать рапорт с подробным изложением причин «почему это сделать невозможно, но я попытаюсь».
                                                              • 0
                                                                написать рапорт с подробным изложением причин «почему это сделать невозможно, но я попытаюсь».

                                                                При каждом потенциально опасном действии? Это будет минимум пара рапортов уже на первый рабочий день, а дальше закономерное увольнение.

                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                              Самое читаемое