34. Заключение

Автор — Бенджамин Латч

Под редакцией Бетси Бейер

Я читал эту книгу с невероятной гордостью. С того момента, как я пришел в компанию Excite в начале 1990-х, где моя команда представляла собой группу своего рода SRE-неандертальцев, отвечающих за «работу с программным обеспечением», всю свою карьеру я пытался методом тыка разобраться в процессах сборки систем. В свете моего многолетнего опыта работы в отрасли высоких технологий особенно удивительно наблюдать, как идеи SRE укоренились в Google и получили столь скорое развитие. Когда я присоединился к Google в 2006 году, служба SRE включала пару сотен программистов, а сейчас тут работают более 1000 человек, которые распределены по дюжинам площадок и поддерживают функционирование, на мой взгляд, самой интересной вычислительной инфраструктуры на планете.

Так что же заставило Google SRE за последнее десятилетие превратиться в организацию, способную интеллектуально, динамично и эффективно обслуживать такую колоссальную инфраструктуру? Я думаю, что секрет этого ошеломляющего успеха SRE кроется в самой сути его принципов действия.

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

Этими решениями впоследствии могут без проблем воспользоваться другие SRE-команды и в конечном счете все, кто так или иначе связан с Google (или не связан… вспомните Google Cloud!) и хочет задействовать или усовершенствовать накопленный нами опыт и разработанные нами системы.

Когда вы приступаете к формированию команды или системы, за основу предпочтительно взять свод правил или аксиом, достаточно общих, чтобы быть пригодными к немедленному использованию, но при этом не теряющих актуальности со временем. Во многом именно об этом и говорит Бен Трейнор Слосс во вступлении к данной книге: о гибком, в основном ориентированном на успешную проверку временем наборе компетенций, который остается актуальным спустя 10 лет после утверждения, несмотря на изменения и рост, характерные для инфраструктуры Google и команды SRE.

В процессе повышения значимости SRE мы отметили несколько разных движущих факторов. Первый — не изменившийся со временем характер основных компетенций и задач SRE: наши системы могут быть в тысячу раз больше или быстрее, но в конечном итоге они должны оставаться надежными, гибкими, простыми в обращении в случае непредвиденной ситуации, хорошо контролируемыми и со сбалансированными мощностями. В то же время привычная деятельность SR-программистов становится более значимой по мере развития сервисов Google и повышения профессионализма самих работников. К примеру, то, что раньше было задачей «создать информационную панель для 20 машин» сейчас может представлять собой «автоматизировать представление, создать панель инструментов и систему оповещения для парка из 10 000 машин».

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

Представьте, что 100 лет назад вам потребовалось бы совершить перелет между двумя городами. У вашего самолета, скорее всего, лишь один двигатель (или два, если вам повезло). Летчик также исполняет роль механика и, возможно, дополнительно грузчика. В кабине есть место для пилота и, если вам повезло, второго пилота или штурмана. В отличную погоду ваш самолетик оттолкнулся бы от полосы, и, если бы все прошло хорошо, вы бы медленно поднялись к облакам и в итоге приземлились в другом городе, на расстоянии, возможно, пары сотен миль от места взлета. Отказ любой системы самолета в то время приводил к катастрофичным последствиям, и нельзя было назвать беспрецедентными случаи, когда пилоту приходилось что-то ремонтировать прямо в полете! Подведенные к кабине системы были жизненно важными, простыми и нестабильными, и в большинстве случаев резервных элементов не предусматривалось.

Прыгнем на сотню лет вперед, в салон огромного Boeing 747, стоящего на взлетной полосе. Сотни пассажиров заполняют обе палубы, в то время как тонны грузов загружаются в нижний отсек. Самолет «напичкан» надежными резервированными системами. Это образец безопасности и надежности, — собственно, поднявшись на нем в небо, вы будете в большей безопасности, нежели на земле в салоне автомобиля. Ваш самолет оторвется от размеченной полосы на одном континенте и свободно приземлится на другой размеченной полосе на расстоянии 6000 миль точно по расписанию, в пределах пары минут от прогнозируемого времени посадки. Но загляните в кабину — кого вы там обнаружите? Все тех же двух пилотов!

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

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