Тёмные боги корпоративной архитектуры
Добро пожаловать в варп! Здесь вы можете добавить ваши ощущения от Ока Ужаса.
Многие пользовались разными мобильными приложениями С7 и фишечками вроде автоматической сдачи багажа, даже болтали с нашим ботом в чатике. Всем этим мы занимаемся у себя в подразделениях.
Меня зовут Андрей Жуков, я директор по ML, AI и другим высокотехнологическим базвордам в ИТ-дочке авиакомпании С7, С7 ТехЛаб. Это подразделение создано в 2017 году под впечатлением от книги Skunk Works и было призвано привнести новые технологии в консервативный мир авиации. Так в авиакомпании и появились разные гики вроде меня. Я очень люблю играть в настолки, даже коллекционирую их. Давно смотрел на Warhammer 40к как на большую и крайне необычную вселенную, читал лор, а недавно мне, наконец, подарили армию орков, которую в последние полгода я мучительно собираю и крашу. Именно вселенная вахи и будет развлекательным обрамлением для дальнейшего рассказа.
Эта статья — попытка рассказать в развлекательном формате о тяжёлых, болезненных и неприятных вещах, которые отзываются либо болью, либо возмущением:
кто такие тёмные боги в архитектуре и откуда они появляются;
какие они бывают, в каком виде предстают перед нами;
как с ними справляться или, по крайней мере, минимизировать их воздействие.
Как возникают божества
Есть такой прекрасный британский автор Терри Пратчетт, который в своих книгах часто обращался к теме появления божеств (Маленькие боги, Санта-Хрякус). Он сформулировал остроумную концепцию, что вера — количественный и ограниченный ресурс. Если следовать этой концепции, ни один бог не может получить силу из ниоткуда — он должен её отнять у других. В некоторых книгах Терри Пратчетта какое-то божество теряет свою силу. Так образуются новые, причём весьма извращенного вида, вроде пожирателя носков или гномика лысины.
Во вселенной Warhammer 40k варп точно так же реагирует на эмоции и верования населяющих вселенную существ. Более того, сила веры может быть настолько сильна, что у орков вархаммера при определённых условиях даже палка может выстрелить.
Важно понимать, что у каждого бога есть свои жрецы, снабжающие его силой, с помощью которой он творит чудеса (или что похуже) и управляет и жрецами, и всеми смертными вокруг.
Жрецы, в свою очередь, создают ритуалы поклонения этим богам, чтобы тем самым производить силу, энергию и прочее, обращая людей в свою веру.
Перекладывая все это на наш реальный мир, можно обнаружить сходство с Законом Конвея, который гласит, что архитектура программного обеспечения неизбежно отражает структуру взаимоотношений в компании. Это касается не только штатной структуры. Многие умудряются вложить в архитектуру ещё и цели, способы борьбы с рисками и отношения с командами.
Таким образом, мы приходим к тезису, что как мы относимся к нашей работе и по каким принципам строим свои приоритеты в команде, так и будет устроено наше ПО.
Расскажу несколько историй о разных продуктах и командах. У них много общих и отличных черт, но большинство из них пострадало от собственных благих намерений.
История первая: о продукте, который так и не смог выйти за пределы внутренней инфраструктуры
Представьте, вы — лид и собираетесь сделать продукт для внешнего рынка. У вас есть идеи и цели, вы со всеми договорились, но в компании принято следовать принципам безопасной разработки ПО. У безопасной разработки есть свои жрецы, и они укажут вам путь.
Допустим, решили заморозить код. Идея неплохая — релизы приостановили, смотрим код и проверяем его безопасность. Но если захотим проверить не только код, но и все используемые образы, их тоже придётся заморозить. А ещё понадобится проверить все используемые библиотеки. Для этого скачаем весь GitHub и проверим его целиком. А разработку желательно загнать в песочницу, чтобы случайно ничего не натворить. Всё процессы проэмулируем. Сделаем препод, чтобы не катить сразу в прод. А ещё лучше, если их будет три, и в каждом мы будем проверять что-то своё. Отключим интернет, чтобы уж точно было безопасно, и все процессы заведём на скачанный GitHub. И вот внезапно основным принципом становится доменная авторизация, а внешние пользователи запрещены. На внешний рынок с такими условиями не выйти. Команда в ярости. Никто не понимает, что происходит.
Добро пожаловать в варп!
Вас затянуло в Око Ужаса, и выбраться отсюда вы сможете нескоро. Знакомьтесь, в варпе вас встречает Бог Безопасности. Он суров, но отнюдь не жесток. Его цель — чтобы всё вокруг было безопасно, без уязвимостей, все вокруг понимали, что делают, и оценивали риски. Поэтому он осторожен. Но иногда его осторожность доходит до паранойи, которая способна погубить наше ПО. Ведь изначально оно должно было работать без всех этих заслонок и заборов.
Понятное дело, что жрецами этого прекрасного бога будет наша дорогая информационная безопасность. Они всегда сопровождают его, даруют ему силу и мешают нам жить. Но это не значит, что они плохие.
История вторая: о продукте, который было запрещено развивать
Обратим наш взор на другую команду. Вы снова, лид. Снова полны надежд. Ваш продукт нужно поддерживать. Для этого есть специальные ребята, которые занимаются этим вместо вас даже по ночам.
Чтобы передать продукт поддержке, его архитектура должна учесть все требования нашей операционки по поддерживаемости. Начинаем этот процесс, а сопровождать нас и показывать, какие ритуалы нужны будут жрецы.
Оказывается, спроектировать архитектуру — недостаточно. Нужно ещё выбрать инструменты.
Поддержка должна понимать язык, на котором будет написан код. И при выборе может оказаться, что она поддерживает всего два. Допустим, можно всё переписать на эти два языка с библиотеками. Но придётся зафиксировать версию. Мы понимаем, как она работает, как прописаны API, какая есть документация, поэтому от неё нельзя отклоняться. Если поддержку устроит только Java 7 — пишем на нём.
Библиотеки тоже нужно зафиксировать и ни в коем случае не обновлять. Причём желательно сделать это без бэкпортов, вдруг они изменят логику библиотеки.
Зафиксируем ОС — например, CentOS 6. Она всем понятна, в неё сложно что-то добавить, а собирать лучше самостоятельно. Ещё и безопасники порадуются.
А теперь новый запрос — убрать все новые модные технологии! «Что вы этот Data Science тащите с ML. Перепишите его на язык, на котором всё поддерживается». А еще, оказывается, надо назначить дежурных, которые будут вместе с поддержкой на связи 24 на 7».
А потом выяснится, что желательно вообще не менять бизнес логику приложения, никогда. Потому что поддержка только-только научилась поддерживать ваше приложение, а переучиваться очень дорого и долго. Даже смещение кнопки в приложении приводит к простоям техподдержки. Более того: даже изменение цвета кнопки.
На этом этапе становится совсем грустно. Снова кто-то стоит за плечом и подсматривает за нами.
Добро пожаловать в варп! Снова.
Здесь нас вяло приветствует новое божество — Бог Технической поддержки. Он не хороший и не плохой. Любит тишину, не любит, когда вокруг шумят, бегают и что-то требуют. Он немного медлителен, но и мы никуда не спешим, а поддерживаем системы. А они должны быть стабильные и классные. Только иногда становится непонятно, живо ли божество или просто так выглядит?
Его жрецы — наши любимые системные администраторы и технологи. Да, им тяжело, непросто, именно поэтому рождаются все те ритуалы, которые будут мешать нам жить.
История третья: о продукте, который так и не был согласован
Допустим, мы решили всё сразу продумать и сделать правильно. А для этого проведем ревью архитектуры и напишем системный дизайн. Для этого есть шаблоны, а жрецы проводят и покажут, как в них всё устроено.
Шаблон заполняем самостоятельно. Архитекторы лишь надзирают, созерцая, но не вмешиваясь. Вот только шаблон оказывается на 50 страниц, и дизайн-документ тоже надо написать. Написали, но архитектурный комитет не готов принять с этим шаблоном — это же архитектурный комитет, серьёзные люди! Сначала нужно пройти несколько комиссий — штук 5. Каждая посмотрит написанное по 5 раз и каждый раз пришлёт комментарии. Проблема в том, что в каждой из этих комиссий вас могут вернуть в начало пути. А 4 уровня архитектуры по модели C4 у вас уже должны быть на этапе дизайна: «Вы же умные, можете рассказать, как у вас код будет устроен.» И кажется, архитекторы ещё изобрели какой-то C5, который тоже надо написать».
Получается, нужна документация по ещё не написанному коду. Желательно её сопроводить, показать, как всё работает, и потом уже начать разрабатывать.
Финальный, пятый комитет документацию возвращает и говорит всё переделать. Мы пошли и ещё раз проделали всё, что было в предыдущих ритуалах. Шаблон изменился. Надо все начинать сначала. Мы вновь возвращаемся на первый круг, и какая-то пустота появляется внутри. Кажется, за нами вновь кто-то наблюдает. Снова мы оказываемся в Оке Ужаса.
Добро пожаловать в варп! Снова.
Здесь нас приветствует Бог Документации.
Он неплохой, просто очень внимательный. Всегда проследит и скажет, где, что нужно поправить и что учесть. Он предусмотрителен — ведь нужно продумать заранее, как и что будем делать. Проблема в том, что иногда это доходит до одержимости. Когда мы целый год рисуем дизайн-документы, а продукт так и не появляется, то что-то здесь не так. Ребята, которые его сопровождают, тоже отличные — это системные архитекторы и системные аналитики. Классно, что они всегда всё опишут и помогут. Но иногда это очень долго.
Со жрецами всё происходит слишком тяжело. Давайте попробуем вообще без правил.
История четвертая: о продукте, который делал больно иначе
Вновь мы собираемся командой, и у нас полная свобода действий! Приходит бизнес и говорит, что команда может делать всё, что хочет и как угодно. Главное и единственное требование — регулярно поставлять ценность. А жрецы всё покажут, работаем!
Но вот ещё одна загвоздка: надо спешить. Ведь ценность сама себя не доставит. Она нужна как можно быстрее. Ещё вчера! Делайте что хотите, как хотите, проектируйте свою архитектуру, но быстро. Тесты не нужны, можно ничего не тестировать, а сразу кидать в прод — прикольно, весело. Аналитика и документация тоже не нужны — все же читали Agile-манифест. Рабочий код важнее документации!
И вот мы зарелизились, теперь пора исправить баги. Но из-за того, что очень спешим, бывают релизы с очень большими проблемами. В результате один спринт работаем, один — чиним.
А бизнес возмущается, что опять нет ценности продукта. Надо сразу всё делать хорошо. И техдолг появляется от того, что просто делают плохо. Да и вообще, техдолг — это не долг бизнеса, он же технический.
И вот мы всё сделали, вроде даже работает. В этот раз дошли до реализации. Но поддержка костылей занимает всё время. И вновь наш продукт остановился в развитии. Единственное, чем мы занимаемся — это починкой.
Ценность мы поставили, всё работает, есть пользователи, иногда довольные. Возникает странное ощущение эйфории — ты же всё сделал. Но понимаешь, что снова тебя тянет куда-то не туда.
Добро пожаловать в варп! Снова.
Вновь мы Оке Ужаса. Вновь перед нами предстает божество. Знакомьтесь — это Бог Ценности.
Он прекрасен, всё время дарит нам много драйва. Постоянно вырабатываются эндорфины — смотрите, фичу зарелизили! Только этот драйв убивает разум, и в какой-то момент мы вообще перестаём понимать, чем занимаемся и зачем. Сопровождают его конечно же различные владельцы продуктов, наши дорогие бизнес-пользователи.
История пятая: о продукте, который так и не появился
И вот мы снова собираемся с командой. У нас полная свобода действий, нам сказали: делайте как хотите.
Команда всё хочет сделать правильно и технологично, а не слушать других. В этот раз мы сами — жрецы! Понимаем, что нам нужны State-of-the-art, лучшие алгоритмы. Внедрим всё, что найдём в архиве по нашей теме. Например, Bleeding Edge технологии, самый классный и новый опенсорс, лучшие языки и фреймворки!
Ещё можно взять статьи из arxiv.org и написать всё самим. У нас же высокая инженерная культура! Все же вокруг ничего не понимают и пишут ерунду, а мы сделаем своё.
Весь код, написанный другими командами — уже legacy. Выкинуть! Поэтому пойдём в соседние команды и причиним добро — у них тоже всё перепишем! А ещё давайте придерживаться чистого кода — это же классно и удобно. И чистой архитектуры! Ну и что, что это долго и нудно — мы настроим все линтеры, будем друг друга постоянно ревьюить.
А ещё хороший код не должен переписываться. Это же метрика, она должна быть нулевой. Поэтому сразу пишем идеально, запроектируем сразу хорошо. Поэтому надо обновить архитектуру!
И вот у нас ревизия архитектуры №666. Прошёл год, мы написали много хорошего красивого кода. Проблема в том, что всё ещё не сделали прототип. Мы только готовимся его сделать — основательно готовимся — везде что-то переписали, в том числе фреймворки и arxiv.
Но что-то здесь не так. Понимаем, что происходит безумие. Мы опять куда-то не туда приплыли…
И снова мы в варпе
Знакомьтесь — блистающий Бог Совершенства.
Главный лозунг — not invented here, как обычно.
Он прекрасен. Ему хочется молиться — он же совершенен! А самое смешное, что иногда это не просто сущность где-то вовне, а ваш собственный IT-император. Проблема в том, что за совершенством можно гнаться бесконечно. Если вы решите, что не напишите ни строчки кода, пока не продумаете, как она будет работать через 5 лет, вы никогда ничего не напишите. Его жрецы — все те, кто всегда хочет сделать хорошо, и которым мешают странные люди, бегающие вокруг.
Попробую закончить счастливой историей.
Заключительная история: счастливая
Мы снова собрались командой. Мы уже видели некоторых богов, и в варп уже совсем не хочется — выбрались, и больше нам там делать нечего!
Вариант как с этим справиться — воспользоваться принципом, что количество веры ограничено и учесть всех богов. Попробуем их противопоставить, ведь ни один из них не плохой.
Бог Безопасности. Нет ничего плохого в том, что мы защищаем себя и наших пользователей, но при этом не доходим до паранойи.
Бог Техподдержки. Наше ПО не должно быть вещью в себе, вечным прототипом, который постоянно дорабатывается, а команда держит это на своих плечах. Когда-то надо отдать часть нагрузки техподдержке, которая будет по ночам отвечать пользователям. Но важно, чтобы она понимала, как это работает. Для этого нужно вместе с ней настроиться — где-то замедлить себя, где-то ускорить их.
Бог Документации. В принципе, документация, системная архитектура и дизайн-ревью — это тоже неплохо. Мы сможем учесть какие-то вещи, которые не видим сейчас, возможно, подскажут старшие товарищи, что они видели что-то нехорошее, чего мы пока ещё не видели. Почему бы не воспользоваться их мудростью?
Бог Ценности. В конечном счёте, продукты создаются для того, чтобы поставлять ценность для пользователей — не для того, чтобы удовлетворить наше эго, а чтобы пользователи были довольны.
Бог Совершенства. Наконец, и про себя не надо забывать. Мы хотим совершенные продукты, классный код, но только без фанатизма, распределяя в нашей жизни всё по частям.
Поэтому наиболее правильный путь здесь — уделять всем аспектам равноценное внимание, без перекосов. Конечно, важно ни в коем случае не обижать жрецов этих богов, иначе вас может настигнуть кара из весьма неожиданных мест.
Заключение
Самое важное, что мы можем и должны соблюдать баланс. Все боги, то есть аспекты и принципы продуктовой разработки равноценны и равнозначны. И не забываем друг про друга, вокруг вас люди, которые тоже хотят сделать хороший продукт.
Широта вашего дизайна, то, как широко вы смотрите на ваш программный продукт, гораздо важнее глубины. Пытаясь проработать каждый аспект ПО максимально, иногда можно слишком сильно увлечься, погрузиться в ересь и хаос, а продукт так и не будет сделан. Не надо так.
Не забывайте, что жрецы — не враги, а вы сами и ваши коллеги.
