Лекция «Поток поставки: от изменения до прода»

Около 65 минут на 18 тем. Прогресс сохраняется, поэтому лекцию можно проходить частями и возвращаться к ней позже.

Начало — да: первые 1 тема открыты сразу, без регистрации. После бесплатной регистрации откроются темы до 2-й — вместе с частью из 54 тестов и монетами за верные ответы. Полная лекция — 99 ₽ навсегда, либо подписка на все лекции платформы от 499 ₽ в месяц.

Восемнадцать тем о конвейере поставки как модели движения изменения. Первая часть вводит стадию как сделку «больше уверенности за больше времени» по определению Мартина Фаулера 2013 года: ранние стадии находят большинство проблем быстро, поздние прощупывают тщательнее и медленнее, а задача конвейера — обнаружить изменения, которые приведут к проблемам в проде, включая производительность, безопасность и удобство использования. Здесь же разведение трёх практик по обязательству, а не по инструменту: непрерывная интеграция сводит работу нескольких разработчиков, непрерывная поставка обещает, что любое изменение может быть выкачено, непрерывное развёртывание выкатывает каждое — и различие определяет, кто или что принимает решение о выкате. Принцип единственной сборки артефакта и термин «стадия фиксации» приведены с точной атрибуцией: книга Humble и Farley 2010 года, глава 5, а не заметка Фаулера. Вторая часть показывает, что логика стадий записана в российской норме: ГОСТ Р 56939-2024 требует пунктом 4.13 обеспечить средой разработки непрерывную интеграцию, даёт ей собственное определение и при этом не называет ни одной системы сборки; пункт 4.14 ограничивает обязательность случаями, когда на стандарт сослались. Третья часть — арифметика ожидания на двух первоисточниках: исследование Google по журналам 9 млн изменений (медиана всего процесса ревью менее 4 часов, медиана изменённых строк 24, медиана ревьюеров 1, сравнение с 15,7–24 часами в других организациях) и многофирменный обзор FCA по свыше чем 1 млн производственных изменений 23 финансовых организаций за 2019 год (1,6% изменений дают инцидент, у крупных 3,8%, 24% инцидентов высокой тяжести имеют первопричиной изменение). Отсюда счёт: сборка занимает около процента пути, и её ускорение вдвое экономит минуты из двух недель, а очередью управляет размер партии. Четвёртая часть — кто разрешает выкат: отрицательные корреляции внешнего согласования со скоростью и отсутствие связи с долей отказов по данным Accelerate 2014–2017, одобрение свыше 90% крупных изменений комитетами в обзоре FCA и предположение регулятора о диспетчерской роли таких комитетов — и граница этой находки в приказе ФСТЭК № 239, где меры ОПО.0–ОПО.4 обязательны для всех трёх категорий значимости. Пятая часть разбирает конвейер как объект атаки: требования 5.12, 5.13, 5.17, 5.20 и 5.21 ГОСТ Р 56939-2024 к сборочной среде, включая журнал шагов сборки и оговорку, что повторяемость сборки не равна бинарной воспроизводимости, а также два кейса — подмена файла исходного кода на сборочном сервере имплантом SUNSPOT и расхождение архива релиза с репозиторием в xz-utils (CVE-2024-3094). Финальная тема собирает двенадцать красных линий темы: от точной атрибуции принципов и неподтверждённых цифр до границы между корреляцией и причинностью.

Ошибки, скорее всего, нет — есть неверное ожидание. Сборка занимает минуты, а путь изменения складывается в основном из ожидания: очередь на ревью с медианой от 4 часов в Google до 24 часов по отдельным измерениям в других организациях, ожидание свободного тестового стенда, релизное окно и время, пока рядом накопится партия соседних изменений. При сборке 12 минут, ожидании ревью 18 часов и релизном окне раз в две недели доля времени, когда с изменением что-то делают, составляет около процента, и ускорение сборки вдвое сокращает путь на шесть минут из двух недель. Это не значит, что быстрая сборка бесполезна: она даёт автору быструю обратную связь, пока он ещё помнит, что делал. Но скорость обратной связи и срок поставки — разные величины, и управляются они разными рычагами. Срок поставки управляется размером партии: по данным Google число полезных замечаний с ростом размера изменения падает, а задержка ревью растёт.

Из этих данных такой вывод не следует, и по двум разным причинам. Первая — методологическая: находка Accelerate построена на опросных данных отчётов State of DevOps за 2014–2017 годы, это корреляция, а не эксперимент, и она говорит, что внешнее согласование связано с худшими показателями времени поставки, частоты развёртываний и времени восстановления, а с долей отказов изменений не связано вовсе. Обзор FCA — наблюдательный, 23 организации, один год, одна страна: комитеты одобрили свыше 90% рассмотренных крупных изменений, а в части фирм за весь 2019 год не отклонили ни одного, и регулятор предположил, что они работают диспетчерской, а не контрольной функцией. Вторая причина сильнее: там, где процедура требуется нормой, корреляции её не отменяют. Мера ОПО.3 «Тестирование обновлений ПО» приказа ФСТЭК № 239 обязательна для всех трёх категорий значимых объектов КИИ. Практический вывод из данных другой: замена тяжёлого внешнего согласования лёгкой процедурой на основе ревью коллег в связке с конвейером, который сам отклоняет негодные изменения, — именно это авторы и рекомендуют.

Нет. Требование пункта 5.13.2.6 ГОСТ Р 56939-2024 звучит как «обеспечивать повторяемость сборки (если применимо)», а примечание к нему снимает вопрос дословно: под повторяемостью имеется в виду обеспечение предсказуемости результатов сборок, обеспечение полного бинарного соответствия результатов повторных сборок не требуется. Заодно стоит проверить второе допущение того же разговора: сам стандарт обязателен не по умолчанию. По пункту 4.14 он становится обязательным, когда необходимость соответствия ему определена нормативным правовым актом, отраслевым стандартом или техническим заданием, и тогда обязательны все требования, кроме рекомендуемых — помеченных словами «рекомендуется» и «может». А вот что требование к сборочной среде действительно содержит и что пропускают чаще: регистрацию всех действий при сборке в журналах аудита с фиксацией шагов сборки, разработанную схему сборочной среды со связями между элементами, ролевое управление доступом к среде и хранилищу и хранение результатов сборки в выделенном хранилище.