Я участвовал во множестве совещаний, где кто-нибудь говорил: «Подождите, почему мы сделали это именно так?», только чтобы обнаружить, что ответ был спрятан в 47-страничном RFC 2019 года, который никто никогда не открывал. Звучит знакомо? Ирония заключается в том, что документы RFC должны предотвращать этот хаос. Вместо этого многие команды создают RFC, которые бегло просматриваются, неправильно понимаются или, что ещё хуже, полностью игнорируются. Но вот в чём дело: хорошо составленный RFC — это как хороший фильм....
Я побывал на достаточно большом количестве архитектурных встреч, чтобы знать, что происходит, когда кто-то упоминает теорему CAP: в комнате становится тихо, головы понимающе кивают, и внезапно все начинают обсуждать устойчивость к разделению, как будто планируют действия на случай ядерной аварии. Дело в том, что беспокоиться настолько сильно, вероятно, не стоит. Не поймите меня неправильно. Теорема CAP — это законная и важная концепция в распределённых системах. Но она также стала техническим эквивалентом спортивного автомобиля на пригородной подъездной дорожке: впечатляет, что он есть, редко используется на полную мощность и иногда используется для оправдания сомнительных решений в 2 часа ночи во время кризисного совещания....
Помните те дни, когда инженеры по обеспечению качества тратили половину своего времени на ручное создание тестовых данных? Вы знаете, этот мучительный процесс копирования производственных данных, их анонимизации (часто некачественной) и надежды на то, что никто не заметит, что ваша тестовая база данных содержит всю историю покупок Джона Смита? Да, эти дни сочтены. Генерация тестовых данных на основе ИИ тихо революционизирует подход к тестированию, и, честно говоря, пора бы уже. Реальность отрезвляет: ручное создание тестовых данных занимает до 50 % времени тестировщиков, а использование производственных данных — это потенциальный кошмар с точки зрения соответствия требованиям....
Каждая компания в сфере разработки программного обеспечения имеет такого сотрудника. Вы знаете, о ком идёт речь. Они закрывают задачи за день, на выполнение которых обычным разработчикам потребуется неделя. Они как свои пять пальцев знают кодовую базу. Они могут отладить производственные инциденты, которые ставят в тупик целые команды. Руководство относится к ним как к уникумам. Инженеры избегают сидеть рядом с ними, потому что те заставляют всех остальных выглядеть плохо. И в глубине души вы задаётесь вопросом: не подхожу ли я для этой работы?...
Существует момент, которого боится каждый инженер — оповещение в 3 часа ночи, когда происходит сбой в чём-то критически важном, и внезапно ваша команда переходит в режим тушения пожара. Настоящий вопрос заключается не в том, произойдёт ли сбой системы (он произойдёт), а в том, насколько быстро вы сможете восстановить её работу. Именно здесь на помощь приходит среднее время восстановления (MTTR), и, честно говоря, это один из самых недооценённых показателей в инженерии. Не потому, что он сложный, а потому, что большинство команд измеряют его неправильно или, что ещё хуже, не измеряют вовсе....