Под техническим обеспечением надежности сайтов понимается набор принципов и методик, позволяющих создавать высоконадежные и масштабируемые интернет-ресурсы и веб-приложения. Как и в любой другой области, в Site Reliability Engineering есть свои особенности и профессиональные секреты. Мы расспросили о них Дмитрия Зайцева, программного директора направления DevOps в Skillbox, CTO/CIO во flocktory.com.
Как появилось и развивалось направление SRE?
Термин Site Reliability Engineering (или сокращенно SRE) вошел в обиход российских IT-специалистов относительно недавно, хотя в недрах Google он существует вот уже без малого двадцать лет, а в публичном пространстве обрел популярность в 2016–2017 годах с выходом книги Ричарда Мерфи, Дженнифер Петофф, Криса Джоунса и Бетси Бейер «Site Reliability Engineering. Надежность и безотказность как в Google». Впервые проектирование надежности веб-приложений и сайтов стало самостоятельным направлением в 2003 году, когда Бен Трейнор Слосс создал в Google соответствующую команду специалистов. Спустя 13 лет в этой корпорации работала уже тысяча инженеров по обеспечению надежности сайтов, и данный опыт стали активно перенимать другие крупные IT-компании: IBM, Netflix, Airbnb, Dropbox, LinkedIn. В больших организациях техническим обеспечением надежности сайтов занимаются целые отделы, в то время как в малом бизнесе указанные функции может выполнять один человек или даже сотрудник, совмещающий деятельность разработчика и специалиста по SRE. Во многих компаниях технологии SRE применяются как часть практики DevOps, даже если это официально не декларируется.
Наиболее важные задачи в парадигме Site Reliability Engineering — это повышение доступности, эффективности и производительности системы, управление ресурсами, исключение простоев из-за обновлений ПО, организация мониторинга и разработка сценариев реагирования на инциденты. Фактически инженер по SRE объединяет в себе часть навыков программиста, специалиста по информационной безопасности и системного администратора.
Почему проектирование надежности сайта важно осуществлять еще на этапе его разработки?
Чтобы потом не упереться в технологии и подходы, которые сложно сделать отказоустойчивыми. Очень часто мы сталкиваемся с ситуацией, когда разработчики создают свой сервис, не подумав о том, что он будет запускаться в нескольких экземплярах и работать одновременно в нескольких версиях. Потом приходится изобретать разные костыли вроде сложных процедур релиза новой версии, так как никто не предполагал, что продукт будет обновляться не сразу весь, а путем выключения части сервисов со старой версией кода и запуска новых с обновленной версией. Иногда компании вынуждены строить систему блокировок для работы с общими ресурсами, если их создатели не предполагали, что одновременно может действовать не один запущенный сервис, а 10–20, да сколько угодно.
Каковы базовые принципы обеспечения надежности сайта?
Самый главный принцип — «задублируй всё столько раз, сколько сможешь». Но поскольку это дорого по деньгам и заметно влияет на производительность, дальше начинаются компромиссы.
Каковы ключевые показатели надежности сайта и как они достигаются?
Я бы выделил честную доступность сервиса для пользователей. Посчитать можно так: общее количество сделанных к сайту обращений нужно разделить на число успешных обращений. Например, за последний месяц к нашему сервису обратились миллион раз. Мы смогли корректно ответить лишь на 998 800 запросов. Это говорит о том, что доступность нашего сервиса за этот месяц составила 998 800/1 000 000=0,9988. Неуспешными обращениями мы считаем все случаи, когда пользователь получил коды ответа 500, успешными — если были получены коды ответа 200. Есть еще несколько способов расчета доступности с более сложными входными параметрами, но на базовом уровне ваш сайт доступен настолько, насколько полно вы смогли ответить на запросы ваших посетителей. Из этого, к слову, следует интересный вывод: самые высокодоступные сайты — это сайты с одним пользователем, совершающим один запрос один раз в отчетный период (если, конечно, не выходит так, что именно в этот самый момент сайт окажется недоступен).
Каковы основные обязанности специалиста по надежности сайтов?
Тут нужно, наверное, пояснить, что под сайтом понимается не обязательно веб-сайт, а само слово с английского переводится как «площадка». Это совокупность технических решений, которые создают ценность для компании и ее клиентов. Например, любой крупный веб-сайт — это не только веб-страницы, но и большой объем аналитики, различных функций. И сайтом, то есть площадкой, можно назвать любую крупную информационную систему, даже если у неё нет собственно веб-интерфейса.
Так какими знаниями и навыками должен обладать такой специалист?
Хорошее понимание внутренностей ОС и сетей. Опыт создания и эксплуатации больших систем. Богатый опыт работы с разнообразными базами данных и серверами приложений, а также вообще серьезные компетенции в индустрии, в области эксплуатации и разработки.
Какие программы или инструменты используются при проектировании надежности сайтов?
Любой редактор текста и любая рисовалка диаграмм. Обычно рисуют в draw.io, пишут на Вики. Не бывает каких-то инструментов, которым можно скормить схему, а они тебе тут же укажут на проблемы и недостатки. В этом основная сложность такой работы — всё строится на экспертной оценке.
Какие программные инструменты используются для автоматизации задач в рамках SRE, таких как управление системой и мониторинг приложений?
SRE — это просто подход к управлению эксплуатацией больших и сложных систем. Вы можете это делать без SRE-команды или специальных SRE-людей, но какие-то практики из SRE вы в любом случае станете использовать. Просто потому, что этим практикам уже много лет и зародились они, возможно, ещё до появления самого термина SRE.
Управление системой всё чаще передается на Kubernetes, в данный момент это решение по умолчанию. А мониторинг сейчас обычно строят на Prometheus либо на его заменах типа Victoria Metrics. Компании с реально крупными продакшенами часто пишут собственные инструменты, потому что из-за размеров их инфраструктуры и прочих ограничений им не подходят стандартные решения. Собственно, Рrometheus именно так и родился.
Какие факторы оказывают наибольшее влияние на надежность интернет-ресурсов?
Обычно у систем, с которыми я работаю, десятки и сотни компонентов, и обеспечение надежности всего сайта — это комплексная задача. Попробую рассказать про самые важные составляющие:
Применяемые технологии и опыт команды в их использовании. Например, SQL-базы данных неудобно задействовать в сложных распределенных системах, но при хорошей сноровке — иногда можно. Но чаще всё равно нельзя.
Наличие опытных людей, которые понимают, за счет чего достигается надежность. Без опыта некоторые вещи сложно предусмотреть. Но какую-то часть опыта можно заменить всевозможными чек-листами из серии «10 пунктов, соблюдение которых сделает ваш сайт более надежным, а волосы более шелковистыми». Книжки, опять же, помогают — я имею в виду книги по SRE от Google, DDIA, старые уже книжки от John Allspaw про web operations и capacity planning.
Вообще, фокус на надежности и готовности бизнеса тратить на это деньги. Даже если мы возьмем очень простой сайт, показывающий котиков и работающий на одном сервере, то простейшим шагом для увеличения надежности будет добавление еще одного сервера, что увеличит расходы на содержание такого сайта в два раза. Уже в этом упрощенном случае у владельца должен возникнуть вопрос: а точно ли увеличение расходов и повышение надежности отобьется в виде прибыли? И ответ далеко не всегда «да». А ведь вся эта надежность — она стоит денег еще и в человеко-часах разработки и эксплуатации, в новых требованиях, предъявляемых системе и ее компонентам.
Одной из основных проблем, нарушающих стабильность веб-сайтов, являются частые обновления, создаваемые командой разработчиков. Как этот фактор учитывается в концепциях SRE?
О, это как раз один из столпов SRE. Тут существует специальная механика под названием «бюджет ошибок». Это когда команда какого-то сервиса совместно решает, сколько времени в месяц их сервис может быть не доступен для пользователя, и этот фактор становится рычагом для замедления или ускорения потока изменений. Приведу пример.
Предположим, мы решили, что сервис может быть недоступен 7 часов в месяц — это примерно 99% доступности. Каждый релиз у нас вызывает какие-то поломки, но мы их быстро чиним и в целом укладываемся в установленное ограничение. Но стоит нам увеличить количество релизов, а следовательно, и поломок — и мы потратим наш бюджет из 7 часов недоступности быстрее, чем закончится отчетный период, то есть месяц. Как только это случится, дальнейшие релизы для нас будут невозможны, нам выключат эту кнопку, условно говоря. И на следующий месяц, благодаря такой жесткой и бескомпромиссной политике, мы должны будем либо согласовать новые цели доступности, либо что-то изменить в наших процессах, архитектуре, сервисах, в чем угодно, чтобы сайт падал реже.
Возможно, нам нужно лучше тестировать наши обновления. Возможно, мы должны поправить мониторинг так, чтобы быстрее узнавать об ошибках и быстрее их устранять. Возможно, мы попробуем изменить сам процесс релиза таким образом, чтобы прерывать деплой кода, который точно рушит продакшен, поскольку мы сможем это увидеть в первые секунды деплоя. На практике я такие барьеры практически не встречал, потому что это звучит довольно радикально даже на словах. А представьте, что вам нужно объяснить этот процесс человеку, который отвечает за продукт и у которого в целях стоит разработка новых фич. Вы же количество этих фич для него уменьшаете с помощью такой механики! Особенно если сервис все еще часто падает.
Обеспечение надежности сайтов и стандартные CMS (WordPress, Joomla, Drupal). Совместимы ли эти понятия? Какие концепции SRE применимы для ресурсов, собранных на движках с открытым исходным кодом?
Совместимы, но лично я очень редко такое видел. Из моего собственного опыта — там всё останавливается на дублировании и включении различных модулей, которые позволяют использовать какое-то общее хранилище данных, типа сессий. Добавляет удобства, если это всё происходит в облачных средах: там можно использовать такие примитивы надежности, как облачные балансеры и всякие георезервируемые базы данных.
Как работают SRE-команды в коммерческих компаниях? Это специальный отдел или эксперты на удаленке, фрилансеры?
В России термин SRE сейчас каждой компанией понимается по-своему, если понимается вообще. Для многих SRE — это такая команда мониторинга: люди, которые делают так, чтобы об авариях узнавали вовремя. Часто они же эту аварию и чинят.
Где-то есть каноничные SRE-команды, которые про надежность и масштабируемость. Но обычно это просто одна из ролей для людей, работающих в сфере эксплуатации, даже если они про это не знают. В общем, это скорее выделенная команда или роль, нежели какие-то внешние эксперты. Фрилансеров в SRE я не видел, но допускаю, что они существуют. Просто работают над долгосрочными проектами.
Чему научится в процессе своей работы человек, решивший стать специалистом по SRE?
В первую очередь — эксплуатации больших систем. Разным практикам обеспечения надежности и масштабируемости. Основам бюджетирования и FinOps. В любом случае это не та роль, которой можно научиться без большого опыта в разработке или эксплуатации.
Несмотря на то что Site Reliability Engineering — область в России относительно новая, специалисты по обеспечению надежности сайтов сейчас довольно востребованы. По данным агентства HeadHunter, на сегодняшний день в нашей стране имеется порядка 390 вакансий для инженеров и разработчиков с навыками SRE, которым предлагаются зарплаты в диапазоне 4 500–6 000 долларов США. А значит, самое время освоить эту прибыльную и увлекательную профессию.
Несколько фактов о Дмитрии Зайцеве
В прошлом Head of SRE, а сейчас CTO/CIO во flocktory.com — помогает компании, которая делает платформу реферального маркетинга для половины магазинов Рунета, не падать в «черную пятницу».
Head of SRE в humaniq.com — помогал стартапу создавать приложение, признанное Top Pick in Blockchain на Disrupt SF 2018 от Tech Crunch.
Head of IT Operations в onefactor.com — помогал строить и обслуживать большие кластеры для обработки петабайтов данных.
Обладает богатым опытом в финтехе, геймдеве, adtech'е и других областях.
Организатор конференций Highload++, DevOpsDays Moscow, DevOpsConf, RITconf и митапа DevOps Moscow.
Участвовал в технической редактуре перевода на русский язык книги «Руководство по DevOps».
Сегодня — программный директор направления DevOps в Skillbox. Отвечает за разработку программы курсов, помогает с выбором спикеров и ревью уроков
