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

Поможет нам в этом Даниил Подольский из NDA. Он начал свою карьеру в IT 30 лет назад в ЦНИИ РТК и провёл в эксплуатации 20 лет. Последние 15 из них рисует архитектуру и пишет код. Это его история про инженера-самурая, который много раз хотел и должен был совершить харакири. Но всё-таки выжил, чтобы поделиться разного рода фэйлами, которые он встретил на своём пути и рассказать, как их преодолеть.

Что такое «не то»

Древняя самурайская мудрость гласит: «Если проект жив, значит, в нём точно происходит что-то «не то». Потому что, каждая программа имеет ошибку. Но могут быть нюансы или разные последствия её существования: 

• Геморройные, когда надо прямо бегать и орать; 

• Катастрофические, когда чинить уже нечего и остаётся только сделать харакири проекта; 

• Репутационные, когда при упоминании проекта — все остальные самураи склоняют головы, чтобы не было видно их сдавленный смех.

Что такое фэйл

Это решение, которое приносит проекту вред. Вред — широкое понятие, тем не менее, всем понятно о чём идёт речь. Если мы просто случайно что-то упустили, это не фэйл, а повседневность индустрии. Если же мы принимаем решение, которое не соответствует требованиям, хотя мы их внимательно читали, то мы просто ронины (самураи потерявшие расположение своего сюзерена), а не фэйлеры.

Виды фэйлов

Фэйлы бывают разные:

• Технические, когда мы приняли техническое решение и облажались; 

• Концептуальные, когда в нашей голове была картина мира, на основе которой мы принимали технические решения, но она не соответствует реальности;

• Бизнесовые, когда у нас есть некая бизнес-модель, и мы облажались именно с ней;

• Социальные, когда мы облажались, потому что руководили командой и делали это неправильно или когда команда руководила нами и делала это неправильно.

Основные источники фэйлов

Основным источником фэйлов является, очевидно, человек. Именно он способен думать и придумывать неправильно.

Второй источник фэйлов, о котором знает каждый самурай, более важный чем человеческий фактор — это unknown unknowns. Если мы вступили на путь самурая, то надо быть готовым к тому, что в проекте обязательно прячутся вещи, про которые мы даже не знаем, что мы о них не знаем.

Цель статьи

Зачем самураю видеть потенциальные фэйлы?

1. Чтобы помочь сделать скучные совещания весёлыми; 

2. Чтобы поднять свой авторитет у коллег. Особенно, когда мы отвечаем: «я же говорил»;

3. Чтобы предотвратить катастрофу. Если мы видим, к примеру, красный флаг, то, возможно, мы можем как-то восстановить, что же в проекте не так;

4. Чтобы стать звоночком к началу поиска новой работы;

5. Чтобы ликвидировать последствия. Дело в том, что сам тимлид не будет сидеть ночами и восстанавливать файлы, поэтому технический персонал должен быть готовым исправлять всё сам;

6. Чтобы знать будущее, если у вас активная жизненная позиция, то есть если вы активно смотрите и действуете.

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

Фэйл №1: неочевидный

Начнём с очень показательного и одновременно непоказательного примера. Представим, что нам нужна система back up/restore. Мы решаем сэкономить и строим её на cron и rsync, а restore делаем руками. 

Возникает стрессовая ситуация, так как rsync распакуется всегда и программист снёс все пользовательские картинки. В 2001 году это были страшные 10 000 картинок. Нужно делать restore, но в напряженный момент даже самурай может перепутать SRC и DST.

Где фэйл? Вроде бы эта ситуация с rsync не должна подходить под определение. А она и не попадает. 

В чём фэйл

Но в чем же фэйл? Ошибка, не в том, что два раза подряд напряжённая ситуация. А в том, что самурай и его воины (команда) решили обойтись без автоматизации, дабы немного сэкономить.

Это концептуальный фэйл, и последствия, понятное дело, катастрофические, потому что починить ничего нельзя.

Красный флаг

В чём красный флаг? В отсутствии автоматизации на рутинных задачах. Если вы приходите в проект, или ваши воины приходят на новый проект, и вам говорят: «да ладно, будем руками катить, зачем нам это CI?», то можете купить красный флажок и махать им на каждом дейлике. 

Фэйл №2: про автоматизацию, двойной

Однажды, самурай и его воины получили в управление 421 сервер клиента по всей России. Они были связаны в межсеть и все были доступны из центрального офиса по ssh через vpn. Когда они начали их изучать, то поняли, что серверы устарели. У них был 8-ой Ubuntu, в то время как актуальной уже была версия 14.

Они решили их всех проапгрейдить. Причём не руками, а на ansible, потому что это модно.

Что пошло не так? У vpn сменился формат конфига и после апгрейда туннели не поднялись. Две недели подряд самурай и его воины звонили на одну площадку за другой и просили залогиниться на консоль, набрать ssh команду с пробросом порта и уже на этот проброшенный порт натравливали ansible.

В чём фэйл

Потом они разобрались, что во-первых, не протестировали процедуру апгрейда. Прогнали её только на тех серверах, которые были доступны без vpn. Во-вторых, им был нужен не absible, а какой-нибудь salt или puppet. То есть такой агент, который стоит на другой стороне, чтобы он мог прийти к ним за новой конфигурацией без всякого vpn.

Апгрейд — это технический фэйл по причине unknown unknowns. Воины и самурай не знали, чего они не могли знать про те сервера, которые собиралась апгрейдить. И последствия явно геморройные. 

А вот выбор неправильного средства автоматизации — это концептуальный фэйл, за что ответственен, очевидно, человеческий фактор. Потому что самурай с воинами сами принимали это решение и всё знали. Последствия — тоже геморройные и репутационные. Геморройные, потому что, если бы они выбрали правильное средство, геморроя бы не было. А репутационные, потому что над ними потом ржал сюзерен (клиент). И когда они говорили, что неплохо бы поднять зарплату, он каждый раз им про это напоминал, чтобы сделать их позицию на переговорах шаткой.

Красный флаг

Красный флаг в отсутствии тестов на одноразовых задачах и недостаточно глубоком анализе рисков.

Поэтому даже если вы собираетесь один раз прогнать процедуру, тесты нужны.

Фэйл №3: высокая производительность

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

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

В чём фэйл

Площадка не выдержала возросшей активности робота. Что надо было сделать? Добавить ручку контроля скорости для роботов, плавно повысить квоту для роботов и мониторить ситуацию в часы-пик. Но площадку и самих роботов обслуживали разные команды. Это принципиальный момент. Поэтому фэйл — технический. Фэйл-фактор — человек. Последствия — репутационные, так как торговая площадка пролежала сутки и надо было ещё 2-3 месяца обратно восстанавливать объём торгов. Потому что пользователям было обидно и они быстро убежали.

Красный флаг

Какие красные флаги мы тут видим? Во-первых, нет модели поведения продукта в целом. Во-вторых, нет ни одного человека, который представлял бы себе поведение продукта в целом. Дело в том, что площадка и роботы представляют собой один продукт. Они друг без друга не нужны. Но команд воинов было две и каждая из них была лишь сама за себя.

Фэйл №4: agile методология

Есть такая хорошая книжка про agile-методологию: «Как программисту выжить в безнадёжном проекте». Но agile также позволяет превратить безнадёжные проекты в короткие безнадёжные проекты с некоторыми перерывами между ними на планирование. Например, был простой, но с объёмной тематикой проект. Эта была задача про картинки, но на самом деле самурай со своими воинами искал ближайшую к заданным координатам точку из данного множества в 140-мерном пространстве. Честно искали по Евклидовой метрике, что, конечно, абсолютно нерешаемая задача. Но есть такая манхеттеновская метрика, которую можно искать, по индексам, если отсортированы отсчёты и по ним сделаны индексы. Это уже задача решаемая, таким решением можно было пользоваться.

В чём фэйл

У них была исследовательская задача, они её исполняли, но закупки железа, так получилось, надо было произвести раньше, чем закончилась задача. Они решили, что agile можно применить к инфраструктуре, то есть купить какие-нибудь сервера, потом из них что-нибудь скомбинировать. Нормально. Так принято в agile поступать.

Они купили 10 серверов по 32 гигабайта памяти каждый. Но через месяц выяснилось что нужно 36 Гб RAM одним куском, чтобы эти индексы загрузить в память. Это концептуальный сбой.

Они думали, что с инфраструктурой можно обращаться по agile. Это оказалось не так. Понятно, что они этого не знали, то есть источник — unknown unknowns. Последствия то ли геморройные, то ли катастрофические.

Красный флаг

В чём красный флаг? В неправильном выборе методологии. Не для всех проектов agile годится. Поэтому если вы вдруг видите, что у вас проект, для которого нужен waterfall, а вам навязывают agile, или у вас waterfall, а вы видите, что можно двигаться короткими итерациями, то вы опять же можете купить красный флажок и помахать тимлиду этим самым красным флажком на дейлике.

Фэйл №5: всё правильно сделал

Есть приложение. Это не instant messenger, но похоже на него. Есть также мобильные клиенты, которые подключаются к серверам и всё время обмениваются сообщениями. Вернее, всё время ждут, когда какое-нибудь сообщение придёт. Расчёт был на 20 миллионов пользователей, так сказал инвестор, но в пике было только 20 000.

Задача обмена сообщениями через websocket не очень тяжёлая. Все 20 миллионов пользователей получилось уместить на пять серверов. Но проблема в том, что если один из серверов рестартует, то надо переподключить 4 миллиона пользователей, которых он в себе вмещает.

Это откровенно долго. Если использовать https на Go, то это занимает 6 часов. Вдвое меньше на Open SSL engine-x — 3 часа. Но в любом случае в ТЗ было написано 7 секунд. Что с этим можно было сделать?

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

Воины решили выбрать третий вариант. В проекте было четыре программиста, из них двое — сеньоры. Они два месяца писали протокол. Только через полгода после этих двух месяцев сюзерен (инвестор) решил, что проект не взлетел и закрыл его.

В чём фэйл

Воины всё сделали правильно, уложилась в ТЗ, даже не очень много денег потратили. По крайней мере, выбрали более дешёвый вариант, чем те самые 112 серверов. Но ресурсы оказались потрачены зря. Это концептуальный фэйл, воины решили рогом упереться в инвестора и сделать всё, как в ТЗ. Хотя на 20 000 пользователей можно было переподключиться на тех самых пяти серверах. То есть источник — это человеческий фактор. Тут не было никаких неизвестных вещей. Они просто решили, что надо так. Последствия репутационные, потому что сюзерен (инвестор) закрыл проект и потерял доверие к своим воинам.

Красный флаг

Покупайте красный флаг, когда вы видите, что в проекте, например, уже полгода выбирают K-Value хранилище, тестируют K-Value хранилища, изучают код K-Value хранилища. Иначе говоря, красный флаг в перекосе распределения ресурсов в сторону задачи, не блокирующей разработку.

Фэйл №6: мы же программисты

Это фэйл, за который самураю стыдно до сих пор, хотя он и не полностью за него ответственен. Произошло это в 2013 году. Даниил собирал команду на новый проект RTB SSP. Если кто не знает, то там жёсткие требования по latency и по параллелизму. Необходимо получить запрос, связаться с RTB DSP, провести аукцион второй цены, сформировать ответы и отдать клиенту. Но запрос до клиента должен ещё доехать. И так как это обычно мобильное устройство, то RTT — десятки миллисекунд. В итоге нужно всё успеть за 250 миллисекунд. Соответственно, RTB SSP свои дела должен сделать за 50 миллисекунд.

Клиентов много, потому что RTB SSP — это такое место, куда ваш мобильник приходит и спрашивает, какую рекламу показать клиенту, и RTB SSP отвечает. Конечно, на деле всё сложнее, но сейчас нас это не интересует.

Поскольку у CTO этого проекта были подвязки в perl-мире, все воины были сплошь из perl’овиков.

В чём фэйл

Вопрос о том, на каком языке лучше писать, активно обсуждается. Самурай, например. считал, что писать надо на GROOVY. Но в 2013 году никто не знал, что это такое. Все думали, что он ещё медленнее, чем Java. Хотя Java, на самом деле, очень быстрая, а GROOVY на данной задаче был бы ещё быстрее. В любом случае ясно, что perl не самый лучший язык. Особенно, под этот проект. Потому, что задача превращается в сложный асинхронный код. Там сложный контроль того, сколько клиентов, на какой демон асинхронно запускать.

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

Они писали этот код целый год. Отлаживали его, профилировали, оптимизировали и тестировали. А тестировать асинхронщину — это прямо привет, какая сложная задача.

В итоге инвестор закрыл проект через год по той причине, что всю работу можно было сделать за 2 месяца на Java. И он был прав.

Это, очевидно, социальный фэйл. Фактор — человеческий, так как люди, которые принимали решение о выборе средств реализации, всё знали. Не было никаких unknown. Последствия — репутационные, потому что инвестор понял, что проект в тупике и его воины не смогут соблюсти требования по ТЗ. То есть выполнить кодекс самурая)

Красный флаг

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

Фэйл №7: бизнесу виднее

Самурай со своими воинами писали финтех стартап, и в этом проекте он был CTO. Писали год, а показывать в конце было нечего. Никакого работающего кода нет. И стейкхолдеры приходили к самураю с вопросами: «Что это? Может быть, ты плохо делаешь свою работу?» Он анализировал: горизонт планирования — шесть недель. Он планировал выйти на «что показать» за три спринта. Это уже такой стандарт. Первый спринт исследовательские задачи, второй — реализация и третий — доработка. А вот горизонт бизнес-планирования, оказался четыре недели, то есть он со своими воинами просто не успевал закончить то, что им заказал бизнес. К тому моменту, когда пора было дорабатывать, к ним пришли новые бизнес-требования.

В чём фэйл

Это бизнесовый фэйл. Можно было бы сказать, что это фэйл концептуальный, потому что бизнес думал, что мы работаем быстрее. Но нет, бизнес так не думал, он всё знал, но не мог дотерпеть. А потому, что команда успела сделать за два спринта, бизнес видел, что проект не выстрелит. Он думал, что две лишних недели платить людям деньги не надо, пусть прямо сейчас начинают заново. 

Фактор — человеческий, потому что конкретный человек принимал на основе информации решения. Последствия очевидно катастрофические, потому что время не вернёшь.

Красный флаг

В чём красный флаг? Если вы год работаете на проекте, а показать всё ещё нечего, то, возможно, пора обновить резюме. Даже если зарплата хорошая. 

Итоги

В конце этого отрезка пути, у самурая и его воинов в руках был таинственный манускрипт на 7 фейлов.

Он, правда, пока не сумел извлечь из него пользы. Это артефакт, который существует сам по себе. Возможно — это удастся вам!

Но вывод самурай всё-таки сделал. Он изменил свой родовой девиз на:

«Нормально делай — нормально будет».

А закончить повествование о пути самурая, можно хайку гениального японского поэта Мацуо Басё, которое он посвятил своим ученикам:

«Не слишком мне подражайте!

Взгляните, что толку в сходстве таком?

Две половинки дыни».

Чёрная пятница продолжается! Только с 5 по 15 декабря видео докладов и презентации конференций 2022 года со скидкой более 50%. В акции участвуют закрытые видеозаписи осенних конференций 2022: Saint HighLoad++, Saint Teamlead, Frontendconf и HighLoad++ 2022. Подробности на официальном сайте