Вчера увидел вот этот пост в LinkedIn https://www.linkedin.com/feed/update/urn:li:activity:6988016347070763008/ с фразой «First rule of programming, If it works, don't touch it» и как-то вскипело. Поясню почему.
Когда я анализирую (умозрительно, или на dev окружении, ни в коем случае не на prod) новую систему заказчика, для которой надо сделать аудит или провести какие-то эволюционные изменения, одна из первых вещей которые я рассматриваю – что тут можно потрогать, потрясти, поменять настройики, удалить, попробовать на зуб и как это отразится на поведении всей системы. Анализ через сценарии «what if» очень важный инструмент архитектора.
Отступая на шаг назад если ситуацию с видео метафорически применять к программной индустрии в значении «First rule of programming, If it works, don't touch it», то создатели арт объекта нарушают сразу несколько очень важных правил построения современного процесса разработки ПО.
Под «современного» я имею в виду не только green field проекты, вокруг которых летают розовые единороги и даже прежде всего не такие проекты. Я имею в виду современный подход, используемый как при разработке новых систем, так и при эволюции и рефакторинге существующих решений.
Прозрачность. Все что происходит внутри системы должно быть легко отслеживаемо. Про любую часть системы должно быть понятно, зачем она тут и что будет если ее убрать.
Воспроизводимость. Любая инфраструктура должна быть воспроизводима и данные должны быть восстанавливаемы простым легко доступным способом. Включая prod. Особенно prod.
Ограничение урона (impact): Ни у кого не должно быть легкого, не аудируемого способа сломать что-то важное или дорогое.
Устойчивость: Архитектура систем должна быть устойчива (resilient). Выход из строя по возможности как можно большего количества подсистем не должен приводить к полному отказу системы. Не должно быть единой точки отказа – того самого сервиса, единичный выход из строя которого ломает вообще все.
Разберем эти пункты детально
Прозрачность: Современные системы состоят из сотен тысяч строк строк кода. И еще несколько миллионов строк к ним добавляют используемые библиотеки. Средняя команда разработчиков за день добавляет/меняет в этом всем может быть 1000 строк, на самом деле обычно меньше. При этом часто чтобы поменять одну строку, надо прочитать (и понять, что написано) дюжину строк кода. Если эта дюжина написана не прозрачно и не понятно, что там делается, то шансы разработчика написать качественный код существенно снижаются. Отсюда следует другая цифра, один блок кода пишется один раз и потом за годы жизни проекта он много раз меняется и еще большее количество раз читается.
Из чего следует простое правило, код должен легко читаться, должно быть легко понятно, что в блоке кода делается и модификация не должна вести к непредсказуемым побочным эффектам.
Если проводить параллель с роликом – на вынутом из фигуры драже (это же M&M’s?) должно быть явно написано «если вынешь, все рассыпится, вообще все» и совсем уж хорошо было скрепить соседние драже клеем, на всякий случай.
Воспроизводимость: Люди придумали компьютеры для того, чтобы они делали работу за нас. У компьютеров есть отличное свойство, они умеют (если им не мешать) делать работу быстро и с предсказуемым результатом. Если мы строим инфраструктуру, то нет никакой причины делать это путем кликания мышью. Давно придуман Infrastructure as a code (IaC) подход. Всегда можно построить еще 10 таких же окружений просто запустив, например terraform и накатив на свежее окружение данные получить среду полностью идентичную предыдущей.
Что в современной парадигме происходит, если джун кладет prod, полностью, в клочья.
ПродОпсы запускают пайплайн на создание нового прода.
Минут 10-20 пока прод поднимается они всей командой вежливо, в корректных выражениях просят джуна больше так не делать.
Проверяют, что все нормально поднялось, тесты проходят и все норм.
Идут писать блог пост с извинениями пользователям.
Проводя метафору с видео, создатель скульптуры должен был сказать джуну «Святые пассатижи, опять! Да сколько можно то? Не делай так больше по возможности.» и запустить процесс пересоздания арт объекта.
Ограничение урона: Все действия с системой должны быть аудируемы и видны широкой аудитории. Не должно быть секретной консоли, в которой админ, один, сидя в темной комнате (темной для придания драматического эффекта) производит тонкие манипуляции над пентабайтами данных, в проде, без права на ошибку. Принципы тут простые.
Если какое-то действие можно сделать кодом и автоматизировать, это должно быть кодом. И что важно код должен проходить через механизм Pull request review. Т.е. на код должен посмотреть как минимум еще один человек. Даже если это проект terraform. Особенно если это проект terraform. Плюс, там, где это возможно код должен быть протестирован авто тестами.
Если действие нельзя автоматизировать и закомитить в репозиторий в виде кода, то
a) Действия должны явно, подробно, занудно подтверждаться в UI – то самое «Вы собираетесь удалить 3 объекта в ресурсной группе. Объекты будут удалены навсегда без возможности восстановления, введите название ресурсной группы, чтобы совершить действие».
b) В особо важных случаях, например надо что-то срочно поменять в базе данных на prod (к сожалению, такое тоже бывает), собирается звонок, один человек, у которого есть доступ шарит экран и делает изменения, остальные участники звонка смотрят, чтобы он не промахнулся.
Возвращаясь к видео – для вытаскивания драже надо было бы создать PR в main ветку и для его мерджа надо бы было получить апрувы от двух синьеров.
Устойчивость (resilience): По возможности все части системы должны иметь какую степень автономности и сохранять ограниченную работоспособность с как можно меньшим числом зависимостей. Самый простой пример – отказ кэш сервиса не должен приводить к выходу системы из строя. «Нет кэша, ну что ж будем работать медленнее».
В случае с арт объектом можно было ожидать, что часть объекта разрушится, но потом осыпание дойдет до circuit breaker и процесс прекратится.
Подводя итог – на видео мы скорее всего видим архитектора или тим лида который забрел к команде разрабатывающей систему по SDLC стандартам прошлого века и нечаянно инициировал им радикальную трансформацию архитектуры и процессов.
