Как продать технический долг с точки зрения DevOps?

Часто драматично и патетически утверждается, что лучше не создавать технический долг. Да, лучше без этого, конечно. Но последствия еще можно устранить. Под техническим долгом я подразумеваю все изменения и улучшения, инфраструктурные модификации и изменения процессов, изменения в структурах команд, направленные на устранение пробелов (сделанных сознательно или нет в рамках запуска продуктов), а также фичи, которые сильно мешают с течением времени. А поскольку подобные вещи невозможно исправить без твердой и уверенной командной игры производственного и эксплуатационного отделов, то этот рассказ непосредственно о DevOps. Технический долг – чей он? Но сначала корень проблемы: почему я вообще говорю о техническом долге? Потому что мне очень обидно, что бизнес не выделяет на это время. Эта красная нить проходит через все отчеты, встречи и общение между разработчиками и операторами. Злой, плохой, ужасный бизнес не выделяет времени на работу с техническим долгом. Возникает даже праведный вопрос: «А качество им вообще не нужно?» Забегая вперед, скажу: «Качество никому не нужно». Но эту мысль я раскрою чуть позже. Чтобы проанализировать эту ситуацию, давайте рассмотрим, почему бизнес так поступает с нами. И чтобы получить ответ, нужно задуматься, чей это технический долг. Кто несет за это ответственность? После многих лет участия я понял, что мы были как Фродо, который предлагал каждому кольцо. Это типа: «Помоги мне нести это бремя!» Мы ждем, что бизнес захочет (именно захочет), чтобы мы разобрались с техническим долгом. Но коренная причина нашего взаимного непонимания с бизнесом в том, что он никогда этого не захочет. Для нас это инженерная задача, способ улучшить качество продукции или даже механизм повышения гордости за нашу продукцию. Но для бизнеса это всегда неприятность, необходимое зло (или необходимость), на которое приходится тратить время. Представьте, вы садитесь в такси, и водитель спрашивает: «Могу ли я остановиться на мойке?» Бизнес в этой ситуации — клиент, а застройщик — таксист. Бизнес возмущается: «Как же?! Я плачу за время в пути, а ты едешь на мойку!» На что таксист резонно отвечает: «Разве вы не хотите покататься в чистой машине, которая хорошо пахнет?» Бизнес отвечает: «Чувак, конечно! Но я ожидаю этого по умолчанию и не готов сейчас ради этого останавливаться на мойке!» Именно так бизнес относится к техническому долгу. Это как предложение заехать на мойку. При заказе такси выбираю соответствующую категорию, чтобы салон был чистый или люкс. На этапе заказа я готов вложиться в это, но заехать на мойку нет. Потому что, как я уже говорил ранее, качество никому не нужно. Но это ожидается по умолчанию. Это обязательно. Предприятия не могут смириться с тем, что не ходят на мойку, и предприятия не могут ходить туда за счет своего времени. Так что же нам делать? Бизнес – это локомотив. Ему нужны функции, продажи и клиенты. Продать технический долг бизнесу через наши «хочу» и «хочу» невозможно. Но можно мотивировать бизнес и по-другому. За время своего пути у меня сформировались 3 категории бизнес-мотивации к «покупке» технического долга: «Жирное» безразличие. Когда есть богатый инвестор, генеральный директор может позволить себе команду разработчиков из странных чудаков. Типа: «Ну и пусть делают! Главное, чтобы продукт сделали, а командный дух — ого, все круто, и у нас была бы лучшая контора в мире». На мой взгляд, это крутой фристайл, который часто приводит к катастрофе, потому что технический долг требует прагматизма. Когда мы не делаем это прагматично, мы создаем Левиафана псевдокрутой архитектуры. Страх. Это одна из наиболее эффективных, распространенных и действенных моделей технического долга. О каком «хочу» здесь можно говорить, когда страшно? Речь идет о том, когда что-то происходит, например, клиент ушел из-за сбоя или взлома. И это все из-за низкого качества, тормозов или чего-то еще. Но прямо продавать из-за страха тоже плохо. Спекуляция со страхом работает против доверия. Продавать нужно аккуратно и максимально честно. Доверять. Это когда бизнес дает вам столько времени, сколько вам нужно для работы над техническим долгом. Доверие работает и сохраняется только тогда, когда вы тщательно малы до общей доли и максимально прагматично тратите это время. В противном случае доверие разрушается. Более того, оно не накапливается. Постоянный процесс идет волнообразно: доверие то возрастает, то угасает. Далее я расскажу о своем опыте и о том, что работает для меня и моей замечательной команды. Насколько глубока «кроличья нора» с техническим долгом? Когда я пришел в новую компанию 3 года назад, мне нужно было понять, насколько велик этот технический долг. О его существовании я знал из статистики обращений, в том числе от бизнеса и партнеров. Мне нужно было понять, с чем я вообще имею дело. Это нормальный и обязательный первый шаг в работе с техническим долгом. Не стоит спешить делать первое, что попалось. Вам следует проанализировать ситуацию в целом. Основываясь на том, что я тогда увидел, у меня возникло предположение, что одна из корневых проблем — большая связанность кода. Сейчас я меньше вовлекаю всех в этот процесс, но тогда я собрал всю производственную команду, чтобы исправить те слои, которые мы хотели подчеркнуть в нашем пакете приложений. В нашем приложении было как минимум 80 различных компонентов (дистрибутивов, а не установок). Разобравшись в ситуации, с ней пришлось разобраться. Этап 1. Виртуальные команды Будучи таким умным, мне пришла в голову идея сделать вид, что у всех есть время, и сформировать виртуальную команду вокруг каждого компонента. Выглядело это примерно так: «Ребята, кто за какой компонент возьмется? Формируйте свои предложения, как его улучшить». Но чтобы не терять концентрацию, мы все вместе сформулировали критерии оптимизации первого этапа: Слабая связь Экономичная масштабируемость Легкое подключение новых разработчиков (простые и понятные принципы: что именно можно делать в этом компоненте, а что нельзя, плюс изоляция кода, который не сможет «потрогать» каждый) Возможность использовать внешний API там, где это необходимо. Доступность предлагаемого стека технологий Оптимизация QuickWin в текущих решениях Простота мониторинга и устранения неполадок Принципы чистоты аудита и лицензии Принципы управления версиями и устаревания Конечно, это был не фокус, а набор критериев практически для всех аспектов разработки программного обеспечения. Весь список можно заменить одной фразой: «Все исправить». Эта фаза закончилась фиаско, в том смысле, что просто ничего не произошло. Мы добились очень незначительного прогресса в реализации некоторых задач, потому что я пытался планировать их с помощью общего журнала невыполненных работ. Задачи были непонятны. Их вводили в работу вручную. Я быстро понял, что тяжело и мне, и команде, плюс постоянно нарастают конфликты и споры. Итак, я перешел ко второму этапу. Этап 2. Технический долг — мой На первом этапе я договорился с генеральным директором нашей компании, что мы введем квоту на отставание. Мы потратим 70% на бизнес-вопросы, 15% на устранение дефектов и 15% на технический долг. Во-вторых, на предыдущем этапе я понял, что если каждый несет ответственность за проблему, то никто не несет ответственности за эту проблему. Это вовсе не бирюзовое заявление. Мне это самому не нравится. Но обратное требует очень высокого уровня зрелости и командной работы. Поэтому я решил сформировать систему технических лидеров. Но я не просто назначил человека техническим руководителем компонента. Я максимально изложил свои ожидания, определил путь их развития и возложил на них ответственность за ситуацию на производстве. Эксперты OPS не спят, если ваш компонент работает с ошибками. Это вы пытаетесь разрешить ситуацию. И вот мы отправились. Есть технические лидеры (ответственные) и квота на технический долг 15% (есть время). Но как в итоге выглядела реальность? Первое, с чем мы столкнулись, это то, что у нас есть FinTech, комплаенс и разделение обязанностей, т. е. я и разработка не имеем доступа к производству и не можем его иметь по определению. И еще, я говорю: «Ребята, вы отвечаете за ситуацию на производстве!» Дайте людям журналы! Когда вы возлагаете на людей ответственность, пожалуйста, дайте им в руки инструмент. И это первое, что мы сделали с экспертами OPS, предоставив техническим специалистам журналы, чтобы они могли видеть журналы своих компонентов. И у нас была по-настоящему совместная работа — наш первый шаг к DevOps, где эксплуатация и разработка работают вместе. Эксплуатация настраивала передачу логов (Кибана и т.п.), а разработка должна была следить за тем, чтобы логи не содержали чувствительной информации (личные данные и т.п.). 5% считаются счастливыми... Реальность такова, что, несмотря на 15%-ную квоту, в каждом спринте случаются какие-то бизнес-кризисы и срочные вливания, потому что «Партнеру это нужно сейчас, иначе он уйдет!» Конечно, этот технический долг сначала выталкивается из спринта — в результате у нас были спринты с 0%. Были и спринты с 15%, но технического долга у нас было всего 5-8% в среднем. Это большая проблема, потому что программист не может знать, сколько времени у него будет на реализацию. Я, со своей стороны, пытался помочь этой ситуации, неутомимо запуская воздушного змея над всеми командами. Мы научились собирать подробные метрики для каждого спринта, и я посмотрел спринт в конце. Взлом спринта — это систематическое нарушение квоты технического долга. Если квота не выполнена за один спринт, это не значит, что все плохо. Действительно, ситуации бывают разные, и нужно проявлять гибкость. Но когда это систематически повторялось, я собирал специалистов производства, спорил и объяснял, насколько это важно и неприемлемо, потому что квота согласована. Моей ежедневной работой было продвижение процесса в этой модели. И оно действительно сдвинулось с места, но теперь я считаю, что у этого подхода есть свои существенные недостатки. Ограничения подхода Владельцы продукта привыкли, что весь бэклог принадлежит им и все задачи координируются ими: «Квота — это хорошо, но только мы решаем, что команда будет делать в этой квоте технического долга!» А когда разработчикам подходили задачи (помните о сильной связности) вроде рефакторинга, устранения шаблонов и т. д., они получали логичную реакцию: «Что?! Какой шаблон? О чем мы говорим?!» В результате на смену задачам пришли те, которые можно назвать техническим долгом, но которые были условно выгодны вендору. Поэтому мне пришлось занять жесткую позицию и сказать: «Техдолг — мой! И я утверждаю, что он будет включен в технический долг каждой продуктовой команды в квоте технического долга на каждый спринт». Вот как мы жили. Хотя мы жили и работали нормально, недоверие росло. Когда мы что-то делаем и никому не рассказываем, что это такое, а время не тратим на бизнес-задачи, всем непонятно, какой результат мы приносим. Поскольку статистика по освоению квот технического долга стремительно росла, мы столкнулись с тем, что не можем заниматься крупными проектами. Кроме того, для больших проектов часто требуется несколько команд. Это было еще и невозможно, потому что каждая продуктовая команда сосредоточена на своем продукте и живет в его реалиях. Их невозможно состыковать по сложной теме. Также никто не включал операции в спринты. У них нет спринтов и бэклогов, как у производства. Они завалены задачами по производству, но это не входило в общие планы. И когда в процессе разработки что-то было сделано в рамках этих небольших частей технического долга для внедрения в производство, это могло оставаться в запросах OPS довольно долгое время. Потому что им действительно было некогда, были загружены дополнительными задачами, мешали работать. Но, несмотря на отрицательные стороны такого подхода, мы добились довольно многого. Чего мы достигли с помощью этого подхода? Сначала мы нарастили мышечную массу с помощью автотестов. Существенно переработав весь процесс CI, мы сделали его цивилизованным процессом, за который нам не стыдно. Во-вторых, мы успешно реализовали борьбу со спагетти-кодом во многих компонентах. Мы сделали модульность и сократили шаблоны. Эти задачи невозможно продать бизнесу даже через страх. Если технологические пробелы в вашем продукте содержат эти проблемы и вам нужно их исправить (если они есть, то их нужно сделать в первую очередь), вам даже не нужно пытаться их продать. Это можно сделать только по модели «Техдолг – это мое», только по квоте. Я видел много попыток и сам пытался сделать это по-другому на первом этапе. Это не сработало. Действительно, работа в таком режиме не может продолжаться долго. Это ограниченный карт-бланш, который вам дает руководство, доверяя вам как техническому директору и руководителю группы. Этап 3. Законный проект Затем мы инициировали третий этап — «законный» проект по работе с техническим долгом. Предполагалось, что мы отходим от закрытой квоты, планируем через общий бэклог продуктов (т. е. владельцы продукта признают, что эти проекты необходимо реализовать) и переходим к чистой продаже. Чтобы это произошло, мы сделали 2 вещи: Я максимально сузил объем работ, которые мы начали делать в рамках этого проекта. У меня сформировались конкретные ожидания относительно того, за что мы будем бороться на производстве. Это был полный отказ от идеализма, потому что наши задачи должны быть максимально прагматичными, понятными и полезными для службы с точки зрения бизнеса. Важным моментом является то, что у нас есть определенная иллюзия, что мы пытаемся рассчитать бизнес-ценность технического долга, хотя это редко возможно. А если его еще можно посчитать, то перед нами кошмарный технический долг! Положительное значение работает лучше для бизнеса, чем отрицательное. Если вы скажете: «Этот клиент уйдет. Он принесет столько-то денег», то пока он не уйдет, это не сработает. Это не бизнес-ценность. Тем более, что культура работы с рисками еще не очень высока, поэтому режим такой: «Нет потерь, пока они не уйдут». Также не обязательно показывать стоимость бизнеса. Где можно показать, а можно показать технологическую ценность, только ее надо посчитать. Руководство о том, как продать технический долг Вот весь рабочий процесс этого этапа продажи технического долга. Выберите область внимания (только одну) Поскольку это продажа через страх, выберите область, которая действительно влияет на ваш бизнес. Направления могут быть разные: доступность, скорость доработки, безопасность A/B-тестов и экспериментов, стоимость доработки. Существует огромное количество направлений и тем. В моем случае я выбрал доступность, потому что она была в центре внимания бизнеса и имела определенное влияние на наш сервис. Очень важно не распыляться и выбирать только одну тему. Проведите интегральный анализ Я проанализировал статистику доступности и инцидентов за год и подробно проанализировал все постмортемы по всем ситуациям, произошедшим в течение года. После этого у меня сформировалось понимание на высшем уровне, над чем нам нужно работать максимально технически, но опять же – содержательно. Первое правило доступности — не пытаться построить систему, которая будет всегда доступна, а быть готовой в случае возникновения инцидента. Это то, что мы должны обеспечить. Вторая проблема и основное правило доступности — это соглашение о деградации: когда-нибудь что-то обязательно произойдет, и вы должны быть готовы сохранить свой сервис, возможно, за счет отказа от некоторых предоставляемых вами функций. Это соглашение необходимо поддерживать, в том числе на программном уровне. Третий вопрос касается мониторинга и наблюдаемости. Это быстрая локализация источников инцидентов и время обнаружения реагирования. Если у вас много ненадежных тестов, вам придется перестать доверять мониторингу. Если в ваших производственных тестах есть инструкции по реакции службы поддержки, например: «Если сообщение не погаснет в течение 5 минут, позвоните мне» — вы не отслеживаете производственную ситуацию. Тест должен быть максимально однозначным: «Показывает — значит где-то беда, поехали!» Выполните покомпонентный анализ Для этого мы сформировали, что именно будем делать по каждому направлению и компоненту. Мы имеем в виду, куда будем перетаскивать service mesh, как будем раскачивать мониторинг и на основании чего. Здесь мы перечислили около 15%, но на самом деле улучшений программы очень много. Мы все это выложили, но это еще не продается. Чтобы выйти и показать это открыто сейчас, мы сделали следующее для каждого проекта этого этапа. Сформулируйте существенные, количественные показатели Мы очень боимся количественных показателей: как можно измерить качество работы разработчиков в количественных показателях? У нас есть много аргументов против количественных показателей, но мы не должны принимать их в лоб. Ценность не следует воспринимать только как ценность бизнеса. Их можно сформулировать, например, как «не более X ложных срабатываний». Вы можете перечислить конкретный набор компонентов, для которых критически важно предоставлять канареечные релизы или возможность гарантировать гарантированный откат патчей. Общая доступность, конечно, должна быть количественным показателем. Это обязательно. Защита проектов Имея этот набор прагматичных проектов, максимально четкие метрики и результаты, которых нам нужно достичь, я сказал: «Ребята, мне нужна квота технического долга. Мне нужно, чтобы вы включили эти проекты в свой пул, чтобы ускорить их, чтобы они перейти к общему планированию на полностью юридической основе вместе с бизнес-целями». Это было услышано, мы это сделали, и это сработало. Думаю, это как на видео, как нарисовать сову: «Нарисуй овал и две черточки». В конце – волшебство – вы получаете сову! Но вся магия в том, что вам нужно реализовать весь этот проект и довести его до конца. Не просто делать какие-то дела в этом направлении, а доводить это до результата. То есть достичь заявленных количественных показателей и показать их. Эту пропасть невозможно перепрыгнуть в 95% случаев. Его нужно перепрыгнуть полностью. Преимущества подхода Итак, мы начали прыгать (через пропасть). Мы делаем это успешно. Сейчас мы находимся на втором этапе этого проекта. То есть мы протащили первый пул проектов и согласовали второй пул проектов. Что изменилось? Повышение доверия Доверие значительно возрастает благодаря открытости, если мы показываем реальные, поддающиеся количественному измерению показатели. Но правда в том, что продажа технического долга происходит из-за страха. Этого шага невозможно избежать. Но не стоит этого бояться или стыдиться. Главное – не спекулировать на страхе, а реально его анализировать, как я показал на разных этапах (интегральный анализ, покомпонентный анализ). Делаем большие проекты Поскольку теперь это узаконенные проекты, мы можем синхронизировать работу разных команд и делать действительно большие проекты. Некоторые проекты выполнялись последовательно от спринта к спринту. За нами регулярно (раз в неделю) отслеживается состав технологической команды и мы понимаем, кто где (на каком этапе). Эта информация максимально открыта и прозрачна. Ход реализации проектов и текущие статусы публикуются и доступны владельцам продуктов (и всем, кто хочет их видеть). OPS'еры в проекте Самое главное, мы поняли, что нам нужно многое перепроектировать в инфраструктуре и процессе развертывания. OPS'еры были явно включены в этот проект. На мой взгляд, это больше DevOps, чем Kubernetes и Docker, когда OPS'еры обсуждают с разработчиками, как изменить архитектуру компонента, а разработчики обсуждают с OPS'ерами, как лучше всего изменить инфраструктуру. Почему я не сделал этого сразу? Здесь мы возвращаемся к тому, о чем я говорил в конце фазы 2: раньше это не сработало бы. Потому что то, что мы сделали на этапе 2 (спагетти-код, который мы перепроектировали, наращивание мышечной массы тестов и редизайн процессов CI), было бы невозможно продать бизнесу в отношении измеримых показателей. Эта ситуация не была связана с каким-либо конкретным страхом, и наш стандартный аргумент: «Нам нужно много времени, чтобы написать код, потому что код-спагетти» — никто в бизнесе не слушает. Таким образом, мы бы не смогли реализовать такой подход. С моей точки зрения, если у вас есть технологическая платформа, требующая такой глубокой инфраструктурной переделки, вам не избежать фазы 2. На это надо пойти, но быть готовым не только все время порхать, как воздушный змей, но и закрыть этот магазин достаточно быстро, чтобы не потерять доверие к своему бизнесу.