Pull to refresh
8K+
5
Сергей Сафонов@gmplays

Целеустремлённый

17,1
Rating
2
Subscribers
Send message

Ирландцы это "no true Scotsman": любой контрпример объявляется ненастоящим. В нашем случае - "при высоком качестве не бывает "не учёл" - а как только "не учёл" случился, значит, качество было невысоким. Проверить такое утверждение нечем, оно всегда право.
Про менеджмент согласен, что не должен. Он и не решает напрямую, он не выбирает, писать ли тесты миграций и делать ли канарейку. Он выбирает, что берём в спринт. "Фича обещана клиенту, надёжность подождёт" по форме приоритет, по последствиям инженерное решение, просто принятое человеком, который за отказ не платит. Бэклог надёжности обычно не проигрывает спор - он в него не попадает.

Соглашусь наполовину. Если "дешевле" результат расчёта, спора нет:, посчитанный трейд-офф эт ровно то, за что статья. Карго там, где "дешевле" никто не считал, а правило осталось. А вот аналогия с SLI, по-моему, работает в обратную сторону. SLO ниже 100% это бюджет ошибок. И весь его смысл - тратить остаток на скорость изменений, пока он не сожжён. Так что зрелая версия правила кмк звучит не "не катим в пятницу", а "не катим, когда бюджет исчерпан" в какой бы день недели это ни случилось.

Учитывая всякие Mythos сейчас в тренде уже продолжение этого "анекдота" - есть два типа людей "те, кто не занимается сесурити-патчингом" и "те, кого уже уволили" :)

"Не принято релизиться в дождь" это мощно! Принято в коллекцию, которую я просил в финале, планка сходу высокая ))
По сути спорить почти не с чем, и особенно ценно, что цену второго пути ты назвал сам - система, умеющая вернуться к последнему рабочему состоянию это человекочасы, а не тумблер. Добавлю одно, из соседней ветки про миграции "сама себя восстанавливает" легко даётся коду и тяжело данным. Разрушающая миграция превращает "забить и откатить" обратно в "править". Поэтому в базовый минимум "выкатить, откатить, уведомить" я бы вписал четвёртый пункт - откат отрепетирован, включая базу. Иначе бамбуковый аэродром никуда не девается, просто переезжает из календаря фризов в ранбук, где слово "откатить" написано, но никем не проверено.

Ровно поэтому бэклог надёжности не выживает в формате "отдельный проект на потом" потому что "потом" не наступает, продукт горит перманентно. Работают, по моему опыту, два хода. Встроить фиксированную квоту спринта или железное "экшены постмортема идут вне очереди"; и положить рядом две цифры - час простоя в деньгах и час работы над канарейкой - разговор с бизнесом после этого другой. Пока надёжность на бумаге бесплатна, она проигрывает "горящему продукту" всегда!

Про миграции спорить не буду, тут ты прав полностью, откат кода - кнопка, откат данных - операция с потерями. Поэтому у миграций свои правила: expand-contract вместо разрушающих изменений, ревью миграций строже ревью кода, восстановление из бэкапа отрепетировано, а не существует в теории.
А дальше мы согласны больше, чем выглядит. "Катить в рабочее время, чтобы не чинить ночью" это правило с названной причиной и ценой. Такие правила статья карго-культом не называет. Карго начинается этажом ниже когда "авось" из твоего же комментария признан погодным явлением и не чинится, тесты миграций никто не пишет, прод знает один человек, бэкап последний раз разворачивали в прошлой жизни. Запрет пятниц тогда работает громоотводом - молнию отводит, проводку не чинит. Статья ровно за то, чтобы называть это костылём вслух и чинить проводку.

От неожиданных проблем никто не застрахован это правда, вопрос в цене реакции. "Кто это будет править" предполагает, что править надо сейчас, руками и срочно. Если откат кнопка, а не спецоперация, то "кто починит в субботу" превращается в "кто жмакнет откат", и для этого не нужен отдел на 40 человек, достаточно одного дежурного с телефоном. Дорого именно чинить руками в выходные, и вот этого маленькой команде правда лучше не планировать.
А если отката по кнопке пока нет тут я с тобой целиком согласен - не катить в пятницу разумно. Статья лишь за то, чтобы называть это честно "у нас дорогой откат, поэтому не катим" а не возводить в стратегию надёжности. Кажется, в этой точке мы уже согласны :)

Спасибо. "Встречаю повсеместно" звучит как та же выученная беспомощность из пункта про ретро, только в масштабе индустрии, когда "не как все" по умолчанию читается как "что-то не так", спрашивать "зачем" перестают раньше, чем успевают попробовать. Лечится, по моему опыту, одним - написанной страницей на вики "почему у нас иначе и что мы за это получаем". Как показывает моя практика, большинство претензий она снимает, а оставшиеся больше уже не претензии, а вкусы.
Я в индустрии десять лет с лишним лет, и это первая статья, которую сел и дописал, ровно потому что надоело встречать это "повсеместно" молча. Хочется хоть немного сделать нашу индустрию лучше. Посмотрим что из этого выйдет ))

Именно! Вопрос "а почему лучше подождать?" обычно вскрывает список как откат руками, мониторинг не ловит, канарейки нет и т.д.. Этот список и есть настоящий бэклог по надёжности, и да, по моему опыту он редко короче квартала.

Про ирландцев лайк )) Мне кажется стейджи никогда не догонит прод (ни разу не видел), поэтому ставка всегда не на идеальную копию, а на умение дёшево ошибаться в самом проде (канарейка, фича флаги, откат кнопкой). А менеджмент, который на словах за качество, а руками просит "побыстрее" это ровно "система принятия решений" из последнего раздела - пока за скорость и за надёжность отвечают разные люди, побеждать будет скорость.

Вот тут заступлюсь за оппонентов немного. "Не может быть "не учёл" не бывает кмк. Тесты снижают вероятность, но не до нуля, иначе постмортемы были бы никому не нужны. Я как "бывший SRE-шник" делаю ставку не "в проде не будет багов", а "баг в проде заметим за минуты и откатим за минуты". Это разные инженерные задачи, и вторая честнее.

Твоя формулировка про микросервисы мне нравится больше моей - "можете ли выкатить багфикс в любой момент недели без боли" - это и есть проверка независимости деплоев, короче моего абзаца. Беру!
Про "нормальный ли проект" соглашусь, пожалуй, наполовину. Тезис не в том, что в пятницу прям нужно деплоить. Симптом это когда пятница вызывает страх и запрет объявлен стратегией надёжности. Если пятничный деплой для вас скучен, но вы его не делаете, потому что незачем, это не карго, это здравый смысл :)

Статья ровно про это. Если "кто-то что-то не учёл" доезжает до прода и всплывает только в выходные, вопросы не к пятнице, а почему тесты это пропустили, почему мониторинг не заорал в первый час, почему откат целое событие, например, а не кнопка. Запрет пятницы как временный костыль, пока это чинится очень разумно, в тексте так и написано. Карго начинается, когда костыль объявили решением и чинить перестали.

Information

Rating
451-st
Location
Valencia, València, Испания
Date of birth
Registered
Activity

Specialization

DevOps-инженер, Менеджер проекта
Ведущий
Git
Docker
Linux
Английский язык
CI/CD
Grafana