Pull to refresh

Comments 16

Самое веселое происходит, когда забывают документацию обновить, а что-то ключевое меняется. Тогда бывает больно в экстренной ситуации.
Не, самое веселое — это когда DPR погдотовлен но не проверен. И когда наступает черный день и активируется DPR, то оказывается что например резервные IP, например, в черном списке РКН.
«Плановая авария на продакшене на 10 минут посреди ночи» это просто замечательный совет. Такое можно проворачивать только в случае, если вы готовы к «щас у нас весь прод упадёт», по-другому лучше даже не пытаться.

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


Сервер должен переживать перезагрузку без недельных плясок с бубном. Иначе у вас большая проблема с отказоустойчивостью и ее надо решать.

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

Это скорее крайний случай технического долга и хрупкой архитектуры.

Тут мог бы быть длинный комментарий, но постараюсь покороче: возьмусь утверждать, что в подавляющем большинстве давно живущих российских компаний малого, среднего и даже большого бизнеса IT-инфраструктура представляет из себя мешанину оборудования разной степени древности и запутанности взаимодействий; непосредственно в сервисах каша не меньшая; причём всё это с минимальным резервированием, счастье были бы рабочие бэкапы.
И основные силы IT-служб уходят на поддержку этого разнообразия в сколь-нибудь рабочем состоянии. Бизнес на все крики, служебки и переговоры кивает головой, но как только дело доходит до денег — моментально сливается. «Работало же всё до этого? Да? Ну вот пусть и дальше работает». И чесаться начинают только когда уже рак вовсю свистит. И крайними ну вот с очень большой долей вероятности так или иначе будут те же айтишники. Которые об этом прекрасно в курсе и ночные аварии «на 10 минут» на боевом окружении в своём уме устраивать точно не будут.

Само собой, что это надо объяснить бизнесу в целом. "Вот смотрите, есть такой риск. Если все сдохнет, будем терять N долларов в секунду. Давайте его снимем"

Начал писать ответ, но притомился, так как получается слишком длинно (но я черновик сохранил, если что).
Краткая мысль, если мы говорим о российском не ИТ бизнесе, то там всё плохо с управлением (хотя и в нём тоже, знаю примеры весьма солидных и известных по именам контор, где просто дикий управленческий бардак).
Я лучше вот такую ссылочку дам, опять же возьмусь утверждать, что она покрывает подавляющую часть российского бизнеса, во всяком случае она разошлась широкой копипастой и везде все в один голос воют, что «это ж про нас»: www.facebook.com/photo.php?fbid=902645646532554&set=a.753933981403722.1073741827.100003613815841&type=3&theater
Это я к чему — управление рисками в ИТ? Не, не слышали.
Тогда, видимо, будет уместна цитата из поста:
Когда IT-отдел месяцами выпрашивает хотя бы пару HDD в старенький сервер для бэкапов, у вас вряд ли получится организовать полноценный переезд упавшего сервиса на резервные мощности.
Ну тогда у вас сферический DRP в вакууме, так бОльшая часть нашего бизнеса так и работает. Я возможно не поленюсь — и допишу свой комментарий, чтобы было больше и понятней про ИТ в таких ситуациях.

а можно ночью не надо, я часто ночью работаю

Устраивайте плановые аварии на продуктиве. Стенды не могут заменить все.

Интерестно, кто-нибудь это реально делает и как это все проводится(в плане ответственности). Ну т.е. если продуктив после этого не запустится, типа проводившему тест придется искать новую работу?
Я что-то с другом понимаю как представитель бизнеса(далекий от IT) будет реагировать на фразу — «эти айтишники что-то там тестировали и положили прод».
Время от времени сервер надо перезагружать. Например, если надо быть уверенным, что всё что на нём крутится, а также настройки сети корректны и запускаются после перезагрузки. Типовая проблема — настроили сеть (например, для связи с другими серверами), а после ребута не встало, а не вставшая сеть чинится посложнее, чем «зайти по ssh». Перезапуск машины время от времени позволяет ночью в час X починить его обычной перезагрузкой и спать спокойно.
Если представители бизнеса сами заинтересованы в этом, то ещё как проводятся. Слышал, что в одном банке от каждой команды (которых не мало) пару раз в год нужно дежурить в ночные часы, когда админы полносвтю выключают и переключают дата центры, именно для этого самого тестирования.
Согласен. У нас тоже проводится подобное. В идеале, это вообще бесшовно для пользователей и сервисов. Просто нагрузка перераспределяется, имитируя отказ одного и или двух ЦОДов.
Sign up to leave a comment.