Date: 2021-02-15
Очень часто драматически и патетически утверждают, что техдолг лучше не плодить — потом не устранишь. Да, без него, конечно, лучше. Но последствия устранить все-таки можно, и глава Программного комитета Артем Каличкин на конференции DevOpsConf 2020 поделился своим опытом в этой области.
Можно спросить, а причем здесь техдолг, если конференция DevOps? Холиварить об этом можно, например, в рамках DevOps-фуршета, но настолько ли это широкое понятие? Мы узнали, что Артем относит к техдолгу все изменения и доработки, инфраструктурные модификации и изменения процессов, изменения структур команд, направленные на устранение гэпов — которые были допущены (осознанно или нет) в рамках запуска продуктов и фич, и которые со временем сильно мешать жить.
А так как такие вещи невозможно исправить без твердой и уверенной спайки производственного и операционного цехов, то и получается, что эта история напрямую — про DevOps.
Почему я про это говорю, какое у меня право? Дело в том, что с operations, production и техдолгом я так или иначе связан 16 лет своей жизни:
До 2004 года я работал программистом-разработчиком на Java в различных компаниях, которые занимаются заказной разработкой ПО, и со временем стал чувствовать себя, извиняюсь за метафору, «суррогатной матерью». Я рождаю какой-то продукт, отдаю его и дальше его судьба мне не ведома. Меня это очень печалило, потому что я хотел знать обратную сторону жизни продуктов — как живет на production то, что я создаю. Эту возможность я нашел в авиакомпании Сибирь (тогда S7 так называлась). Пришел я туда системным аналитиком, а уходил с позиции заместителя директора по IT. Отвечал я за внедрение программных продуктов, ввод и разворачивание новых инфраструктур на — конечно же — production.
В авиации уже в те годы степень зависимости от автоматизации была очень высокой. Это одна из передовых отраслей с этой точки зрения — по крайней мере, в нулевых годах она в этом шла впереди планеты всей. Например, в 2006 году по всему миру отменили печатные билеты, остались только электронные. А сама авиационная деятельность напрямую влияет на бизнес-процессы, на судьбы людей, на всю нашу жизнь. Остановка этих систем и инфраструктур приводит к тяжелым последствиям для огромного количества людей — это и задержки вылетов, и проблемы с регистрацией. Так что по ночам спать я перестал уже тогда. Я уже 16 лет по ночам сплю, вздрагивая, потому что имею отношение к обеспечению на production жизни сервисов, которым стоять никак нельзя.
Но со временем я все-таки понял, что хочу заниматься не только operations, то есть не только вопросами эксплуатации, но разработка мне тоже близка. Мне захотелось заниматься всем производственным циклом, что я и нашел в компании Центр Финансовых Технологий — в рамках тех сервисов, где я сейчас работаю, мы обеспечиваем полный производственный цикл: от идеи до production (включая сам production), обеспечение и доступность.
Здесь, правда, спать стало еще тяжелее, потому что это финтех. Здесь не то, что простой, а задержки со скоростью проведения платежей уже вызывают праведный гнев у клиентов. О потере, порче или неконсистентности данных говорить вообще нельзя — это недопустимо в принципе с финансовой информацией и персональными данными (как и в авиакомпаниях, конечно).
С 2018 года я стал техническим директором сервиса Faktura.ru — это интернет-банк для физических и юридических лиц. И ко всему прочему в моем багаже добавился еще и фактор highload, то есть 10000+ tps, внезапные наплывы пользователей и совершенно безумная, непонятно с чем связанная, активность пользователей на production. Это теперь моя реальная жизнь — я отвечаю как за производство, так и за эксплуатацию.
И на всём своём пути я всегда боролся за качество продукта, потому что я все-таки люблю спать по ночам. Я боролся за то, чтобы уделялись время и усилия повышению качества продукта и устранению технологических гэпов, которые так или иначе неизбежно закладываются на проектных этапах.
И я хочу поделиться этим опытом, моей рефлексией и теми выводами, к которым я пришел спустя долгие 16 лет, особенно на базе последних 3 лет, что я работаю в Faktura.ru. Здесь мне удалось реализовать интересную комбинацию, так сказать — каскад подходов, и у меня окончательно сформировалась мысль, как же делать техдолг. И эта каскадная структура — та фишка, про которую я хочу вам рассказать.
Но для начала — корень проблемы — почему мы вообще говорим о техдолге? Потому что нам очень обидно, что бизнес не выделяет на это время. Это просто красной нитью проходит через все доклады, митапы, коммуникации разработчиков и эксплуатации — злой, плохой, страшный бизнес не выделяет время на работу с техдолгом. Возникает даже праведный вопрос: «Им вообще что ли качество не нужно?!» Забегая вперед, скажу: «Качество никому не нужно», но эту мысль раскрою чуть позже, пусть она вас пока побомбит.
Для анализа этой ситуации давайте задумаемся — почему же так бизнес с нами поступает? И для получения ответа надо задуматься над тем, а вообще техдолг — это чья головная боль? Он чей?