Распределенные системы сложны. Высокопроизводительные распределенные системы сложнее. В такой среде, где каждый день возникает необъяснимое поведение, оценка программного обеспечения практически невозможна.
Просто для справки: в настоящее время я работаю в CHAOSSEARCH, бостонском стартапе, создающем аналитическую платформу Data Lake при поддержке S3. Последние четыре месяца я встраивал в нашу систему события в реальном времени. По сути, это позволяет пользователям вставлять документы и быстро индексировать их с помощью Elasticsearch Bulk API, а не загружать документы пакетами в S3 и ждать несколько минут.
На то, чтобы функция заработала, ушло три месяца. Потребовалось еще полтора месяца, чтобы заставить функцию работать.
В первый месяц я был невероятно наивен. Добившись быстрого прогресса в тестовой среде, я понял, что это вопрос нескольких недель, прежде чем Real-Time выйдет за дверь. Но по мере того, как я все глубже погружался в нашу систему, объем проекта расширялся, и мой мысленный срок отодвигался все дальше и дальше назад.
К третьему месяцу, когда мы сосредоточились на выпуске для клиентов, я создал поток тестов производительности, тестов задержки, реальных тестов и стресс-тестов. Каждый новый тест означал неприятное обнаружение полудюжины новых ошибок. Здесь проблема с управлением потоком, там медленный запрос. Каждая ошибка вынуждала меня вникать в части кода, которые я ранее не замечал, полагая, что они «просто работали». Было тяжело, но я многому научился.
Разработка высокопроизводительной распределенной системы в масштабе — действительно трудная проблема, с которой компьютерная наука все еще сталкивается. Невероятно сложно держать в голове все знания и ограничения, которые вам нужны в данный момент времени. Иногда кажется, что система ведет себя действительно недетерминировано. Явная грандиозность этих систем и бесконечное пространство проблем чрезвычайно вознаграждает. Но это также делает оценку программного обеспечения практически невозможной.
Оценка программного обеспечения хорошо вписывается в Окно Джохари, лихо описанное Дональдом Рамсфелдом (Есть известные известные). Классическая оценка выглядит примерно так. Мы оцениваем все пункты нашего списка дел, все наши карточки JIRA (Известные известные). А затем мы дополняем его временем для задач, в которых мы не уверены (Известные неизвестные).
Конечно, это верно только в том случае, если мы учли все неизвестные (то есть не существует «неизвестных неизвестных»). В реальной жизни это нереалистичное предположение. Но тем более применительно к сложным системам. Распределенная система битком набита «неизвестными неизвестными». Разработчики, не подозревающие об этом, в конечном итоге тратят 80 процентов нашего времени на то, что, по их мнению, должно было составлять 20 процентов работы.
В распределенной системе «неизвестные неизвестные» прячутся за каждым углом. Простое добавление параллелизма в смесь добавляет целые новые классы ошибок, такие как условия гонки и взаимоблокировки. Распространение программы по компьютерам может привести к сбоям в работе сети и проблемам с синхронизацией. В сочетании с высокопроизводительной системой, постоянно перемещающей терабайты данных, вы быстро научитесь предвидеть неожиданности.
В начале третьего месяца мне казалось, что у меня осталась всего неделя или около того работы. Я ошибся. На завершение проекта Real-Time ушло еще почти полтора месяца. И еще много работы для будущих клиентов. Я попал в ловушку, классическую для младших разработчиков вроде меня: я оптимистично оценивал то, что знал. Так что теперь, когда меня спрашивают, сколько времени, по моему мнению, займет проект, я откладываю. Я спрашиваю других людей, с которыми работаю, обдумываю все, чего еще не знаю, а потом просто добавляю кучу дополнительного времени. Потому что я знаю, что 80% моего времени будет потрачено на выполнение 20% работы.
