Comments 6
В подобных историях, включая притчу про остров, поражает, что для того, чтобы спланировать и сделать всё по уму сразу и подстелить соломки ресурсы, обычно, не находятся. Зато чтобы героически исправлять последствия ресурсы находятся всегда и в неограниченном объёме…
А я ещё притчу знаю, в тему. Про двух дровосеков, которые поспорили: кто больше за день нарубит деревьев. Один не переставая молотил и радовался, когда слышал, что второй каждый час делает паузы на 10 минут. "Устаааал, не вывоооозит, обгоню, надо поднажать!!!", - думал первый. Однако, на подведении итогов второй обошёл почти вдвое. Выяснилось, что 10 минут в час он точил топор.
А вот в коммерции почти всегда "надо поднажать!!!", потому что в отчёте наверх строчка "стабилизировали деплой, перебрали кластер, сделали детерминированной сборку образа" не отвечает на вопрос: "А какие business values вы добавили за месяц работы"?
Ну, классика, в целом, в самом начале статьи:
я НЕ девопс - мне пришлось этим заниматься
Проблемы от недооценки рисков, отсутствия DR стратегии и, видимо, экономии на специалистах.
Хорошо ещё, если после таких инцидентов выводы действительно делаются.
Вы очень точно описали ситуацию, только не в том порядке. Сначала идёт экономия на специалистах, отчего хороший (тешу себя мыслью) тимлид и играющий фулстек сеньор садится разбираться с CDK, далее, по классике, эффект Даннинга-Крюгера после пары-тройки успешно сделанных по аналогии несложных изменений и, отсюда же, отсутствие DR стратегии. Знаете во сколько лет я узнал этот термин? Только что, от Вас, спасибо, BTW.
интересный кейс, а как у вас организован процесс деплоя? есть ли предиктивв-чеки которые ловят подобное до проды - план ресурсов или хотя бы линтер который проверяет что все ссылки резолвятся?
Процесс сейчас такой: cdk diff перед каждым деплоем, деплой только конкретного стека, никакого deploy --all. Плюс правило, что сетевое на месте не правится: нужна другая раскладка - переименовываешь construct и получаешь create-before-delete вместо попытки перекроить живое.
Честно про предиктив-чеки: на момент инцидента автоматического гейта не было, и это была главная дыра. Причём план ресурсов у нас был - CloudFormation в диффе честно писал Replacement: True. Просто читал его человек, в конце рабочего дня, глазами, и увидел то, что хотел увидеть. Информация была, гейта не было.
Что мы из этого сделали:
cdk diffв CI, вывод грепается на replace/destroy. Есть замена ресурса - пайплайн краснеет и требует явного подтверждения руками. Самое дешёвое из всего списка и ловит ровно наш класс аварий.Termination protection на стеки с состоянием и RemovalPolicy.RETAIN на базы. Это уже не предиктив, а страховка на случай, когда предиктив не сработал.
Разнесли сеть и базу по разным стекам. Радиус поражения стека равен всему его содержимому, и пока база лежала в одном стеке с VPC, любая правка сети была ставкой на данные.
Про линтер отдельно: cfn-lint по синтезированному шаблону как раз делает то, о чём вы спрашиваете - проверяет, что ссылки резолвятся и типы сходятся. Вещь полезная, но нашу аварию он бы не поймал: шаблон был идеально валиден. Он просто делал не то.
В этом, наверное, и мораль. Линтер ловит невалидное, а больно делает валидное. Поэтому гейт стоит вешать не на вопрос “правильно ли написано”, а на вопрос “что именно при этом будет заменено”.
Тимлид и subnet-полукровка: как одна строчка в YAML стоила $50 000 и двенадцати часов прода