Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 26
По поводу деплоя в пятницу вечером главный вопрос, а нормальный ли у вас проект, что он требует такие деплои?)
По поводу релиза микросервисов, 50/50. Вопрос скорее нужно так сформулировать, можете ли вы отправить безболезненно багфиксы в течение недели в любой момент.
Чем больше деплоев, тем лучше. Хорошо на тронный проект сам выкатывается по необходимости, даже в выходные
Ну разработчики за четверг что-то написали же, почему это не зарелизить в пятницу?
Если это что-то срочное вроде багфикса, выкатывайте, если же новая фича, дождитесь понедельника.
Понятно что если фича нужна на выходных, вроде ивента на праздники, выкатывайте. Но, если это спокойно может подождать понедельника, лучше подождать. Актуально только для небольших команд, где нет постоянной службы поддержки пользователей.
Но, если это спокойно может подождать понедельника, лучше подождать
Это такой же карго-культ про которые статья. Вскрывается банальным вопросом - "а почему лучше подождать?".
Собственно, ответ на этот вопрос - это задача для sre/devops, причем скорее всего, это будет что-то вроде эпика от "на пару спринтов" до "цель на Q5"
От неожиданных проблем никто не застрахован. Вот представь что случилась проблема, даже и небольшая, кто это править будет? Да, если у вас у компании IT отдел с техподдержкой 40-50 человек, то уже можно подумывать о постоянной возможности деплоя.
От неожиданных проблем никто не застрахован это правда, вопрос в цене реакции. "Кто это будет править" предполагает, что править надо сейчас, руками и срочно. Если откат кнопка, а не спецоперация, то "кто починит в субботу" превращается в "кто жмакнет откат", и для этого не нужен отдел на 40 человек, достаточно одного дежурного с телефоном. Дорого именно чинить руками в выходные, и вот этого маленькой команде правда лучше не планировать.
А если отката по кнопке пока нет тут я с тобой целиком согласен - не катить в пятницу разумно. Статья лишь за то, чтобы называть это честно "у нас дорогой откат, поэтому не катим" а не возводить в стратегию надёжности. Кажется, в этой точке мы уже согласны :)
Ну вот допустим Ваше " Вот представь что случилась проблема, даже и небольшая, кто это править будет?" это ответ на мой исходный вопрос "а почему лучше подождать?". Такой ответ порождает дальнейшую ветвь обсуждения - "а проблему прям нужно править?".
Что я тут имею ввиду - при деплое мы можем или собственно править - пытаться какими-нибудь костылями подпереть релиз, лишь бы он поехал, лишь бы циферка версии обновилась, либо забить = откатить.
В первом случае мы снова проваливаемся в тот же devops-cargo-cult - мы следуем каким-то практикам не потому что так лучше, а потому что мы думаем что так лучше, и пофиг на цену, а это и сломанный IaC, и "неудачный я выбрал день чтобы бросить курить"-devops (это был буквально я и мне очень не понравилось), и бутылочное горлышко в виде упомянутого выше devops, и сломанного ttm, и прочего печального.
Во втором случае мы вышли (но это не точно, скорее - наверное выходим) из порочного круга мантр "после 17 не катить"/"в пятницу не катить"/"в дождь не катить" (и это не шутка, работал я в компании в которой было не принято релизиться в дождь). НО - здесь естественно так же есть своя цена, а именно нужно потратить человекочасы на такую систему, которая способна сама себя восстанавливать к последнему рабочему состоянию.
Именно это я и имею ввиду под "это задача для sre/devops, причем скорее всего, это будет что-то вроде эпика". SRE должны находить такие узкие места и улучшать их, делать рабочие механизмы релиз-менеджмента (выкатить, откатить, уведомить как базовый минимум) вместо собирания бамбукового аэродрома "на следующей неделе фриз, потому что наш devops в отпуске в ПНД из-за той каши yaml'а, которую ему некогда разгрести, потому что у него 9000 релизов в сутки"
"Не принято релизиться в дождь" это мощно! Принято в коллекцию, которую я просил в финале, планка сходу высокая ))
По сути спорить почти не с чем, и особенно ценно, что цену второго пути ты назвал сам - система, умеющая вернуться к последнему рабочему состоянию это человекочасы, а не тумблер. Добавлю одно, из соседней ветки про миграции "сама себя восстанавливает" легко даётся коду и тяжело данным. Разрушающая миграция превращает "забить и откатить" обратно в "править". Поэтому в базовый минимум "выкатить, откатить, уведомить" я бы вписал четвёртый пункт - откат отрепетирован, включая базу. Иначе бамбуковый аэродром никуда не девается, просто переезжает из календаря фризов в ранбук, где слово "откатить" написано, но никем не проверено.
я бы вписал четвёртый пункт - откат отрепетирован
Это 100% точно да, прямо как в анекдоте про категории людей и бэкапы, мол на самом деле их не 2 "те кто делает" и "те кто уже делает", а 3 - "те кто уже проверяют что разбэкапливается"
UPD: про "не катить в дождь" забавно, что у этого была своя причина, которую впоследствии починили, но привычка дуть на воду, после того как обожглись на молоке оставалась.
Именно! Вопрос "а почему лучше подождать?" обычно вскрывает список как откат руками, мониторинг не ловит, канарейки нет и т.д.. Этот список и есть настоящий бэклог по надёжности, и да, по моему опыту он редко короче квартала.
и да, по моему опыту он редко короче квартала
И то при условии что других задач нет, чего почти никогда не случается потому что "релизим СРОЧНО, продукт горит!"
Ровно поэтому бэклог надёжности не выживает в формате "отдельный проект на потом" потому что "потом" не наступает, продукт горит перманентно. Работают, по моему опыту, два хода. Встроить фиксированную квоту спринта или железное "экшены постмортема идут вне очереди"; и положить рядом две цифры - час простоя в деньгах и час работы над канарейкой - разговор с бизнесом после этого другой. Пока надёжность на бумаге бесплатна, она проигрывает "горящему продукту" всегда!
Твоя формулировка про микросервисы мне нравится больше моей - "можете ли выкатить багфикс в любой момент недели без боли" - это и есть проверка независимости деплоев, короче моего абзаца. Беру!
Про "нормальный ли проект" соглашусь, пожалуй, наполовину. Тезис не в том, что в пятницу прям нужно деплоить. Симптом это когда пятница вызывает страх и запрет объявлен стратегией надёжности. Если пятничный деплой для вас скучен, но вы его не делаете, потому что незачем, это не карго, это здравый смысл :)
По деплою в пятницу не согласен. Разработчик делает изменение, тесты проходят, деплой проходит, дальше выходные - и начинается, нужно откатить и.к. кто-то что-то не учел и по факту приложение работает, но неправильно
При высоком качестве проекта на прод выкатывается протестированный ког, в котором не может быть "не учел"
Даже при высоком качестве проекта(настоящие ирландцы передают вам привет), не всегда можно сделать тестовый контур такого же объема с теми же данными, что и прод. И часто бывает так, что на словах менеджментом постулируется высокое качество, а на деле сам требует это качество снижать в угоду скорости выкатки.
Про ирландцев лайк )) Мне кажется стейджи никогда не догонит прод (ни разу не видел), поэтому ставка всегда не на идеальную копию, а на умение дёшево ошибаться в самом проде (канарейка, фича флаги, откат кнопкой). А менеджмент, который на словах за качество, а руками просит "побыстрее" это ровно "система принятия решений" из последнего раздела - пока за скорость и за надёжность отвечают разные люди, побеждать будет скорость.
Вот тут заступлюсь за оппонентов немного. "Не может быть "не учёл" не бывает кмк. Тесты снижают вероятность, но не до нуля, иначе постмортемы были бы никому не нужны. Я как "бывший SRE-шник" делаю ставку не "в проде не будет багов", а "баг в проде заметим за минуты и откатим за минуты". Это разные инженерные задачи, и вторая честнее.
Статья ровно про это. Если "кто-то что-то не учёл" доезжает до прода и всплывает только в выходные, вопросы не к пятнице, а почему тесты это пропустили, почему мониторинг не заорал в первый час, почему откат целое событие, например, а не кнопка. Запрет пятницы как временный костыль, пока это чинится очень разумно, в тексте так и написано. Карго начинается, когда костыль объявили решением и чинить перестали.
Потому что все учитывать и покрывать невозможно, либо супер дорого, потому что каждый следующий тест стоит дороже предыдущего, каждый новый ранбук засоряет контекст и так далее. В конечном итоге в большом проекте не деплоить в пятницу просто получается дешевле.
По той же причине у вашего сервиса sli не 100%, и за этим никто не гонится
Осознанный текст - написанный через жизненный опыт. Но к сожалению рынок таков что "стериотипы" подходов копируют из проекта в проект. И если ты не делаешь как все - вывод что наверное что то не так. В целом все что автор описал - встречаю повсеместно
Спасибо. "Встречаю повсеместно" звучит как та же выученная беспомощность из пункта про ретро, только в масштабе индустрии, когда "не как все" по умолчанию читается как "что-то не так", спрашивать "зачем" перестают раньше, чем успевают попробовать. Лечится, по моему опыту, одним - написанной страницей на вики "почему у нас иначе и что мы за это получаем". Как показывает моя практика, большинство претензий она снимает, а оставшиеся больше уже не претензии, а вкусы.
Я в индустрии десять лет с лишним лет, и это первая статья, которую сел и дописал, ровно потому что надоело встречать это "повсеместно" молча. Хочется хоть немного сделать нашу индустрию лучше. Посмотрим что из этого выйдет ))
Касаемо деплоев в пятницу - это все, конечно, замечательно. Ну тут много интересных вопросов насчёт откатов и тп. А мы уверены, что разработчики написали все нужные тесты, тщательно протестировали миграции и их откат, точно знают как устроен прод и способны вернуть его в то первоначальное состояние? А то как обычно какой-то гений написал скрипт который пол базы данных перехреначил, а несчастный девопс должен подключиться и восстановить продовую бд из бэкапа. Тут вопрос не к карго-культу, а к тому что вы не учитываете любимое многими авось, потому никаких деплоев в пятницу. Строго в отведенное рабочее время, дабы не работать по ночам и выходным. А тем кто хочет деплоить по пятницам - желаю вечность работать по ночам и выходным, тогда наверняка дойдёт, почему изменения в продакшене всегда и везде должны производиться строго в рабочее время.
Про миграции спорить не буду, тут ты прав полностью, откат кода - кнопка, откат данных - операция с потерями. Поэтому у миграций свои правила: expand-contract вместо разрушающих изменений, ревью миграций строже ревью кода, восстановление из бэкапа отрепетировано, а не существует в теории.
А дальше мы согласны больше, чем выглядит. "Катить в рабочее время, чтобы не чинить ночью" это правило с названной причиной и ценой. Такие правила статья карго-культом не называет. Карго начинается этажом ниже когда "авось" из твоего же комментария признан погодным явлением и не чинится, тесты миграций никто не пишет, прод знает один человек, бэкап последний раз разворачивали в прошлой жизни. Запрет пятниц тогда работает громоотводом - молнию отводит, проводку не чинит. Статья ровно за то, чтобы называть это костылём вслух и чинить проводку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Карго-культ DevOps: чек-лист самопроверки