Желудевое вино против бюрократии

Откуда берется множество требований

У брокерского бизнеса есть регулятор – Центральный банк Российской Федерации. Это очень строгий регулятор. Он постоянно придумывает какие-нибудь регуляторные требования, приходит к нам с ними и не просто выпускает их, но еще и смотрит, соблюдаем мы их или нет.

Слово «аудит ЦБ» – это у нас такая страшилка-пугалка в компании. Иногда один аудит заканчивается и сразу начинается следующий. Какая-то бесконечная история. Аудиторы приходят и смотрят, как мы соблюдаем регуляторные требования. Поэтому мы не можем просто взять и внедрить какое-то изменение в базу 1С.

Нам всегда нужно держать в голове, что к нам может прийти аудитор и спросить: «Кто это сделал? Почему? Кто это согласовал? Кто прорабатывал методологические требования? А наши регуляторные требования вы вообще читали? Мы их вчера выпустили. Где они у вас?»

Из-за этого вокруг разработки возникает очень много требований. Есть отдельные требования к самой разработке, а есть требования к оформлению, чтобы всегда была видна вся цепочка: кто согласовывал, кто придумал изменение, кто прорабатывал требования и так далее. Все это нужно хранить так, чтобы быстро показать аудиторам.

Несколько лет назад мы перешли на Git. Переход дал нам неблокирующую, достаточно параллельную разработку, и поток задач в нашу базу сильно увеличился. Насколько я помню, раньше у нас было один-два релиза в неделю и какое-то количество задач. Сейчас релизы выходят каждый день, и в каждом примерно столько же задач.

Поток задач увеличился за счет Git. Но, несмотря на CI/CD, автотесты, Sonar и все остальные страшные слова из DevOps, увеличился и поток багов, которые мы привносим в конфигурацию.

Управленцы смотрят на это и, конечно, не говорят нам: «Давайте писать больше автотестов». Они говорят: «Давайте закрутим гаечки. Давайте придумаем, как ограничить поток багов в develop».

Как инструкции превращаются в ШПТ

Сначала появились постмортемы. Случился баг – приходят к разработчику и спрашивают: «Почему ты сделал этот баг?»

Разработчик отвечает: «Я вообще не подумал».

«Почему ты не подумал?»

«Я не знал, что надо подумать».

«Почему ты не знал, что надо подумать? Тимлид куда смотрел? Почему не проверил?»

По результатам постмортема появляется инструкция: разработчик должен подумать о чем-то конкретном перед внедрением. Например, если меняется интеграция, разработчик обязан проверить, что после успешной выгрузки объекта он удалился из плана обмена, а если выгрузка по какой-то причине не прошла – объект из плана обмена не удалился. Перед внедрением разработчик должен пройти по пунктам такой инструкции и поставить галочки, что все проверил.

Потом появляется следующий баг. Разработчик что-то не проверил. Его спрашивают: «Почему ты это не проверил? У нас же инструкция написана».

Он отвечает: «Я не знал, что надо читать эту инструкцию».

Тогда появляется инструкция о том, какие инструкции разработчик должен читать и в каком случае. Эти инструкции на инструкции начинают копиться. Если изменение такое – нужно сделать вот так, если другое – иначе.

В конце концов все это привело нас к ШПТ. Страшное слово расшифровывается как «шаблон плана тестирования». Это огромный документ – условно, в Word или Confluence, – в котором хранится информация о том, что разработчик должен проверять в зависимости от того, что он пытается внедрить.

Это даже не мастер, где можно поставить галочки и получить только актуальные вопросы. Там есть все. Разработчик должен пропустить неактуальные секции, но не просто пропустить, а написать, что пропустил их именно потому, что они неактуальны, а не потому, что забыл проверить.

Так к регуляторным требованиям добавляются наши внутренние требования вокруг разработки. И все это нужно совместить и правильно оформить. Например, в заголовке merge request должна быть ссылка на задачу Jira. Задача Jira должна быть правильно оформлена, а в ней должна быть ссылка на ШПТ, если в рамках задачи есть изменения. И таких связей много.

Но самое страшное даже не это. Разработчик условно за 30 секунд пишет одну строчку кода, а потом должен пройти по всему этому богатству и проверить, что все правильно оформил, все посмотрел и ничего не забыл. Потом он приходит к тимлиду и говорит: «Тимлид, я все сделал».

Тимлиды у нас ответственные, поэтому тимлид должен перепроверить за разработчиком, что тот правильно все оформил. Он сидит, проверяет и говорит: «Все, ты молодец, ты сделал».

Merge request принимается, но на этом история не заканчивается. Когда начальник управления подтверждает выпуск релиза, он, по-хорошему, должен еще раз проверить все принятые merge request и убедиться, что они оформлены правильно.

Получается, три высокооплачиваемых специалиста заняты какой-то неведомой работой, которую, по-хорошему, надо автоматизировать.

Бюрократия

Из школы я помню примерно такую картину: XVIII, XIX и XX века, мануфактуры, разделение труда, резкое повышение производительности. У человечества появился избыток, и оно рвануло в наше светлое будущее к ИИ.

Но при подготовке статьи я услышал идею и теперь вынужден с ней согласиться: производительность труда выросла не только и не столько из-за мануфактур, разделения труда и конвейеров, сколько благодаря бюрократии.

Я всегда был против бюрократии. Думал, что моя миссия – бороться с ней изо всех сил, потому что она бесит. Но оказалось, что бюрократия – это процессное управление. Процесс описан, человек должен по нему пройти независимо от того, как себя чувствует. У него может быть все хорошо или плохо с женой, собака могла рожать всю ночь, он не спал, кто-нибудь побибикал ему по дороге на работу – неважно. Он должен приехать и пройти по процессу.

Именно этот обязательный процесс приводит к тому, что хаоса в производстве становится меньше. А это и повышает производительность труда. Интересное мнение.

Раньше я думал, что бюрократия – это однозначно плохо. В маленькой компании я приходил к боссу и говорил: «Босс, у нас сервер что-то не справляется, ему плохо, не хватает ресурсов».

Он отвечал: «Неси счет».

Я приносил счет. Босс говорил: «Отдай в бухгалтерию». Все. Компания развивается, все счастливы, люди не простаивают, все замечательно.

Сейчас я прихожу к начальству и говорю: «У нас на раннерах очередь – 2 000 заданий. Все просто дымится. Давайте купим железо».

Меня спрашивают: «Сколько нужно денег?»

«Да там копейки. Миллионов двадцать».

«Сколько?! Ты что? У нас бюджеты. Мы не можем. Мы бы рады, но не можем».

Меня это всегда бесило. Разработчики часами сидят и смотрят, когда очередь рассосется. Проблему надо решить, компания станет работать лучше, производительность разработчиков вырастет. Но нет: мы придумали бюрократию и бюджеты и как будто остановили развитие компании.

Однако бороться с этим бессмысленно: все большие компании одинаковые. Значит, нужно как-то примирить бюрократию и работу разработчиков.

Как примирить управленцев и разработчиков

Я технарь, разработчик и DevOps. DevOps, грубо говоря, мирит администраторов и разработчиков.

Администраторы – это ребята, которые говорят: «Мы только-только все сделали, стабилизировали. Не трогайте ничего, все работает».

А разработчики отвечают: «Ха, давайте все перепишем».

Этот лед и пламя надо как-то примирять. И DevOps мирит их не разговорами, не болтовней и не всякими митингами, а инструментами.

Здесь я почувствовал то же самое. Есть управленцы, которые хотят все закрутить, зарегулировать и заставить разработчика делать что-то дополнительное. И есть разработчики, которые вообще не хотят этим заниматься. Их тоже нужно примирить.

Свою миссию как автоматизатора труда разработчиков я вижу в том, чтобы разработчик был максимально эффективен. А когда разработчик максимально эффективен? Когда он внезапно занимается разработкой.

Как только разработчик начал заниматься не разработкой, его эффективность упала в плинтус, а то и ниже. Опытные управленцы могут сказать: «Он может эффективно разрабатывать не то». Но зато эффективно. Пускай не то, но эффективно.

Нужно сделать так, чтобы разработчик занимался только разработкой. А всю остальную кухню переложить на какой-нибудь инструмент.

Первым на ум приходит CI. У нас есть любимые пайплайны, есть merge request, в нем есть pipeline, и там можно проверить все что угодно. Казалось бы, достаточно добавить еще одно задание.

Например, в заголовке merge request должна быть ссылка на задачу Jira. Чтобы принять merge request, нужно, чтобы задача Jira была правильно оформлена и согласована. Делаем простую джобу: она получает данные merge request, выковыривает имя задачи Jira, идет в Jira и проверяет, согласована задача или нет.

Если согласована – все хорошо, джоба зеленая. Если не согласована – красная, все падает. Прекрасно. Но жизнь вносит свои коррективы.

Обычные задания в pipelines

На раннерах стоит очередь из 2 000 заданий. У разработчика все зеленое, кроме проверки задачи Jira. Он бежит к начальству и спрашивает: «Ты чего заявку Jira не согласовал?»

Начальство отвечает: «Забыл!», – и согласовывает. Разработчик даже видит, что все уже согласовано. Он возвращается к себе, нажимает «Перезапустить джобу», и она улетает в конец очереди из тех самых 2 000 заданий. Очередь будет рассасываться еще часа полтора, пока раннеры все прокачают.

Разработчик сидит и понимает, что уже не попадает в релиз. Хотя он глазами видит: теперь все зеленое.

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

Очереди на раннерах не подходят для проверок, которые относятся не к репозиторию, а к внешним системам. Здесь нужно что-то отдельное и быстрое, что может сходить во внешнюю систему и сразу вернуть результат.

Сервис внешних проверок

На помощь пришел механизм status checks – внешних статус-проверок GitLab.

В нашем примере добавлены две проверки: согласована ли заявка Jira и есть ли ссылка на ШПТ. В настройках Status checks указываются имя сервиса и URL. Сам URL определяем мы.

После этого при любом изменении merge request GitLab формирует пакет, в который складывает ID проекта, ID merge request, заголовок и другие поля, и отправляет его на указанный URL.

Что находится на этом URL и как обрабатывается запрос, решаем мы. Для программиста это рай: можно сделать и проверить что угодно так, как нам нужно. Нужен только веб-сервер, который примет пакет, распарсит его, что-то запустит, выполнит проверку и вернет результат в GitLab.

В настройках есть флаг «Status checks must succeed». Если его установить, merge request нельзя принять, пока все внешние проверки не пройдены. Мы прямо в настройках репозитория указываем, что эти проверки обязательны.

Если флаг убрать, проверки остаются видны, но не блокируют merge request. Блок Status checks становится оранжевым. Сразу видно, что заявка не согласована или в задаче Jira нет ссылки на ШПТ, и не нужно никуда отдельно ходить.

Таких проверок можно быстро сделать много. Результат виден сразу. Остается написать веб-сервер, который примет пакет, распарсит его и запустит нужную логику.

One Script External Checks GitLab Service (OSECGLS)

Здесь начинается наша «осенняя» магия. У нас есть «осень» и «вино» – веб-сервер, написанный на OneScript. На OneScript можно писать контролы и все остальное, то есть условно на языке 1С.

Любой разработчик 1С может зайти в проект, понять, что там происходит, и написать собственную проверку, которая его уже задолбала. Если человек постоянно вручную проверяет одно и то же, он может просто реализовать эту логику.

Проект называется OneScript External Checks GitLab Service, сокращенно OSECGLS https://github.com/Golovanoff/osecgls.

Что он умеет?

Структура проекта довольно простая: несколько классов, немного модулей и контролы, которые я накидал. Autumn – это вообще прекрасно, удивительно и представляет собой огромный мир.

В проекте уже есть две проверки. В папку app/checks можно складывать собственные проверки. Весь основной функционал работает: туда можно добавлять свою логику, и она будет запускаться.

Сервис принимает запрос от GitLab и сразу возвращает код 200, чтобы соединение с GitLab не висело. Затем запускается фоновое задание, которое распарсивает пакет, анализирует данные и возвращает результат: хорошо или плохо.

Результат внешней проверки отправляется обратно в GitLab через API. Сервис сообщает, какая проверка должна быть красной, а какая зеленой.

Есть небольшой механизм фильтрации. Сервис может обслуживать несколько GitLab и несколько проектов, причем в каждом проекте можно использовать свой состав проверок.

Например, в URL после HTTP и порта указывается check. Если обратиться просто к check, запустятся все проверки. Если через слеш указать имя проверки, запустится только она. Если через запятую перечислить несколько проверок, запустятся только они. Такая небольшая фильтрация позволяет проверять разные вещи в разных проектах.

Кроме отправки результата как внешней статус-проверки, в autumn-properties можно изменить способ отправки результата. Тогда сервис сформирует новое обсуждение в merge request – условно, откроет тред с комментариями. Такой результат тоже может блокировать принятие merge request, если какие-то проверки не пройдены.

Также сделано несколько контролов: для просмотра логов, перезапуска и обновления.

Autumn вообще не славится отсутствием boilerplate, но в примере получается около десяти значимых строк с логикой. Все остальное – обвязка.

Часть кода скрыта за общей функцией получения задачи Jira. Она получает структуру задачи и находится в общем модуле. Но в целом проверку можно написать быстро.

Если что-то постоянно раздражает, можно проверить что угодно: наличие файла на сетевой шаре, данные в Jira, информацию в GitLab или любую другую доступную систему внутри контура.

Если действие алгоритмизуется, его можно переложить на машину. А если управленцы написали инструкцию о том, что нужно проверять, значит, скорее всего, это алгоритмизуется. Можно заставить машину выполнять все эти проверки вместо человека.

Код достаточно простой. Сначала получаем задачу. Если при получении возникла ошибка, возвращаем ее. Если данные заявки получены, проверяем, согласована ли она, и возвращаем истину или ложь. Сервис сам упакует результат в формат, который нужен GitLab, и отправит его либо создаст комментарий.

Механизм получается простым, но у проекта есть небольшие недочеты.

Маленькие недочеты

Первый недочет – в названиях проверок можно использовать только латиницу. Это кажется ерундой, хотя крови мне попило. GitLab почему-то не понимает русские символы в URL внешних проверок. Если называть проверки латиницей, все работает хорошо.

Второй недочет – сервис приходится перезапускать. Я не знаю точную причину, есть только подозрения. Примерно раз в неделю сервис загружает процессор под потолок и наглухо вешает компьютер, так что до него вообще невозможно достучаться.

У меня есть подозрение, что дело в OneScript 1.9: переполняется какой-то счетчик фоновых заданий. Фоновых заданий много, за неделю они накапливаются, и при попытке создать новое что-то происходит.

Я настроил ежедневный перезапуск сервиса. Для этого даже написал контрол: можно сходить по URL через cURL, и сервис перезапустится. Это занимает около двух секунд. После этого все работает стабильно.

Третий недочет – GitLab не всегда присылает то, что нужно. Если для одного merge request подряд запускается несколько проверок, первый пакет GitLab отправляет правильно, а во втором условно говорит: «Посмотри в предыдущем».

Поскольку мой сервис рассчитан на несколько GitLab и несколько проектов, такие пакеты со ссылкой на предыдущие данные я просто отбрасываю. Проверка не станет зеленой, но ее можно быстро перезапустить кнопкой «Повторить».

Еще одно важное ограничение: external status checks доступны в GitLab Ultimate. Если используется Community Edition, этой функции нет и напрямую воспользоваться ею не получится.

Именно поэтому я добавил отправку результатов в виде комментария к merge request. Даже в Community Edition можно настроить webhook и указать, что при изменении merge request должен вызываться определенный URL. Сервис получит тот же пакет, обработает его и сформирует комментарий в merge request, где будет описано, что сделано правильно, а что нет.

Но здесь есть нюанс, для которого как раз ждем ваших merge request в проект.

Появление комментария в результате внешней проверки – это тоже изменение merge request. Получается цикл: merge request изменился, пошел на проверку, сервис сформировал комментарий, merge request снова изменился, опять пошел на проверку и снова получил комментарий. Возникает бесконечный цикл.

Было очень интересно поймать это у нас на «проде». Меня долго ругали, а я говорил: «Это не я, у меня все нормально». Потом нашел все в логах и раскопал причину.

Исправить это можно, например, добавив условие: если изменение merge request заключается только в появлении нового комментария, ничего не делать. Нет смысла перезапускать проверки, если изменился только комментарий.

Кто-нибудь это напишет, если ему будет нужно. Мне не нужно – у меня Ultimate.

Как инструмент развивается внутри команды

Надеюсь, инструмент кому-то пригодится в работе. У нас он работает.

Пока реализованы две проверки. Сейчас я достаточно активно рассказываю об инструменте нашим разработчикам, чтобы они сами писали проверки. Ко мне уже приходили люди и спрашивали, как это делать.

Я проводил воркшопы и показывал маленькие функции «ВыполнитьПроверку», которые можно написать буквально за 15 минут, если вы понимаете, что именно хотите проверять.

Надеюсь, инструмент начнет развиваться не только моими силами и кому-то еще пригодится.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.