Круши, ломай, устрой дестрой
На войне нельзя: атаковать собственные позиции, и форсировать реки вдоль.
Но иногда надо, и даже полезно.
Знаете, есть шутка которая не шутка: есть три типа людей. Не делает бекапы, теперь делает бекапы, теперь проверяет бекапы.
К сожалению (или к счастью), ряд ваших узких мест вы сможете на практике узнать только одним способом — попытаться всё сломать. После того, как ломали (или даже сломалось) — понять, что пошло не так, где именно, и как мы собираемся с этим знанием дальше жить.
Мое мнение, если коротко: ломать надо.
Да, больно; да, повышает нестабильность и у всех будет гореть жопа.
Но тут как в спорте. Лучше вы дойдете до объективных границ ваших возможностей в предсказуемой, контролируемой обстановке. И хотя бы узнаете, где те границы вообще были.
Во-первых, это честно. Во-вторых, контролируемый эксперимент всегда лучше отказа в неподходящий момент явочным порядком.
Главное, как обычно, план эксперимента. Мы можем и должны предполагать, что что-то пойдет не так: собственно, это и надо выяснить. Надо сделать так, чтобы планово сорванные защиты и клапана не превратились в неплановый чернобыль. То есть — наличие запасных планов и killswitch. Они вам все равно по жизни понадобятся, вот, хороший повод озаботиться заранее.
Дальше — как фишка ляжет. Возможны потери. Кстати, вы знали, что на плановых военных учениях потери до 4% техники и личного состава считаются приемлемыми?
Зато узнаете много нового. Вспоминая про бекапы, мы как-то выяснили, что восстановить мастер-базу в одной большой конторе за обозримое время (в случае ее полной потери) мы не сможем никак. Потому что она в самом оптимистичном случае будет восстанавливаться 5.5 календарных суток. За пять дней полного downtime весь бизнес конторы, 24×7 на глобусе — встанет и сходит нахрен с рынка. Вероятно, надо придумывать варианты.
Но кстати, насколько мне известно, они до сих пор так живут.
Ломали мы всё это на контролируемом, отдельном окружении (патамушто сыкотно было) и правильно делали. А как ты еще такие вещи узнаешь. Что с ними потом делать — вопрос отдельный; умные люди придумали матрицу рисков неспроста, а возможных ответов обычно более чем один.
Можно риски никак не адресовывать. Прагматичный, вдумчивый подход с надеждой на отечественный «авось». У нас просто удача прокачана. Вы же самые удачливые на рынке, слепой лось, горящий лес, вас ведет судьба (ц).
Совсем хорошо, если критические эксперименты уже заложены в план, во фреймворки тестирования и в инженерные средства. Подход «бухая обезьяна», когда на системе можно включить (рубильником) эмуляцию проблем, и рандомно — например — нарушить связность и data integrity в ряде предсказуемых, но заранее неизвестных мест. Особенно весело такое делать на модной красивой микросервисной архитектуре, когда любая мелкая шестеренка внутри вашего инженерного кадавра может непредсказуемо уйти в down и/ли начать творить дичь.
Если вам стрёмно так делать — это хороший маркер именно того, что надо пойти и сделать. Если вам страшно куда-то руками лезть, что вы делать-то будете если оно само отхлебнёт? Ручки из жопки, в глазу слезинка? «Вовремя» так то никогда ничего не ломается.
Хотя у некоторых оно и само падает регулярно во всех местах по аналогичной схеме (Яндекс, привет), даже эмуляция не нужна: D
Дальше вы просто должны понять, как вам с этим жить. Средств и механизмов решения — много. Но они сложные, недешевые, и сами по себе несут значительное усложнение и инженерные нагрузки.
Регулярно встречается еще такая беда: вот у нас есть базовый flow, который работает через жопу; вот у нас есть альтернативный, который работает как failover когда базовый лёг к херам. Если отказы базового случаются часто — альтернативный становится новой нормой, потому что часть процессов и работы ложится на него уже в ультимативно-обязательном порядке. А значит, он становится уже не вспомогательным костыликом, а такой же потенциальной точкой критического отказа. И значит, ему тоже нужны средства failover и альтернативные решения… oh, wait.
Но вы хотя бы это померили, и об этом теперь знаете.
Был замечательный случай, когда мы должны были пойти и наебнуть инженерку в одной из критических частей энергетической инфраструктуры региона. Без имён, мало ли интернет большой, но думаю кто участвовал — помнит этот гэг. В общем, надо было триггернуть системы защиты и ввода резерва на большой хрени, от которой зависит существование 2-3 малых городов. Потом сымитировать отказ, возгорание, и грамотный mitigation, в смысле аварийные планы, пожарная команда итп.
Стоит комиссия. Триггернули защиту. Ввод резерва за тягостные 20-30 секунд не делает нихера. Должен запуститься аварийный ввод для аварийного ввода. В машинном зале подозрительная тишина. Главный инженер тихо седеет под белой каской, и сам становится цвета той каски. Из аварийного блока, куда бочком-бочком позади комиссии тенью перемещаются инженера, появляется сизый дым с ароматом паленого машинного масла.
В плане же был заявлен пожар, ну.
Пожарная команда, которая разумеется была в курсе, и приехала на 20 минут раньше (а им чо, по приколу кататься на наши танцы, не на смене же сидеть сычевать), со двора интересуется: это мы уже горим? А то возгорание-то должно быть во дворе, там даже материал вон сложен, лежит ждёт загорает. Им машут «сыбитесь пока что с глаз, сами разрулим». Наши заливают АВАР из огнетушителей, и начсмены сдавленным голосом драматическим шепотом орет на пульт в рацию «не включать нахрен».
Комиссия одобрительно цокает: смотри-ка, как оперативно справились.
Несмотря на горелый шкаф, лучше так, чем никак.
Честность эксперимента может вам ощутимо выйти боком в корпоративной среде, имейте это в виду. Там аккуратнее надо с выводами. Потому что итоги такого эксперимента могут быть слишком честными — на фоне того, что все стопудово по цепочке вертикали всё прошедшее время усердно отчитывались что «у них всё хорошо». То есть, вероятно, заблуждались. Мы же не должны предполагать, что кто-то намеренно игнорировал и замалчивал проблемы, фу, как вы могли такое подумать-то о людях вообще.
— Папа, а что такое косность и безразличие?
— Сына, я не знаю и мне похуй (ц)
Тут дальше вопрос, что вам важнее: честность и объективность, или нарисованные отчеты и чей-то job security. Я инженер, мне важнее первое (за что я несколько раз в жизни поплатился, ну очевидно). Но все еще важнее, физику не наебешь.
Очевидно, что непонятная и внештатная ситуация, которую вы руками нашли и адресовали, становится уже чуточку более понятной и рассмотренной.
Получившееся пепелище следует описать (см «постмортем») и включить найденные выводы себе в материалы (см «как это обрабатывать»).
Процессы и административные механизмы тоже можно и нужно шатать. Планово и внепланово. Как минимум, определите болевые точки, наличие «непонятных вопросов» и поймете зависимость от специалистов. Но тут, кажется, надо будет отдельно писать.
А еще планы надо актуализировать. То есть, не выдумывать периметр и средства поражения, а хотя бы пойти и узнать актуальные существующие. Чтобы не получилось как у тех генералов, которые всегда готовятся к прошлой войне.
Обычно кстати упомяну, что лучше к ломанию привлекать внешних специалистов. Потому что человек, который в устройстве системы прекрасно разбирается, он и ломать ее будет корректно и предсказуемо. А надо, чтобы честно.
Предсказуемые и понятные точки отказа в данном случае плохи как раз тем, что они предсказуемые и понятные. А вам нужны реальные и практические, это не одно и тоже. Практика отличается от теории именно тем, что отличается от теории.
Итог один: будете крепче спать.
И возможно, появится ряд баек, которые можно будет коллегам рассказать.