Как убедиться в том, что создаваемое вами сегодня программное обеспечение выдержит испытание временем? Наймите инженера по надежности.
Как убедиться в том, что проектируемые вами программы и сервисы не перестанут и в будущем соответствовать нуждам клиентов и потребителей? Если этот вопрос для вашей организации актуален, вероятно, вам нужен инженер по надежности систем (systems reliability engineer, SRE). К данной категории относятся инженеры-программисты, отвечающие за надежную и безотказную работу приложений как в ближайшем будущем, так и в долгосрочной перспективе, с учетом требуемой масштабируемости.
«Иногда их называют инженерами по надежности сайтов или инженерами по надежности сервисов, но в любом случае эта роль неразрывно связана с концепцией DevOps, которая завоевывает все большие симпатии ИТ-служб, – указал проповедник DevOps и специалист компании VictorOps по инцидентам Джейсон Хэнд. – Чаще всего такие люди востребованы в организациях, занимающихся облачными сервисами, SaaS, PaaS и IaaS. Они должны обеспечивать функционирование своих сервисов в течение 24 часов 7 дней в неделю и 365 дней в году. Организациям, которым важна надежность, безотказность и устойчивость, SRE необходим как воздух, ведь каждая минута простоя оборачивается серьезными потерями».
Кто такой SRE?
Чем занимаются SRE? Иногда они представляют собой некий гибрид разработчика и системного администратора, ведающего одновременно написанием нового программного кода и обеспечением бесперебойной работы программных сред и приложений.
«На многих предпритиях есть как те инженерные команды, которые отвечают за клиентские приложения, так и те, что занимаются базовыми системами. Но есть и SRE, взаимодействующие с этими командами на протяжении всего жизненного цикла разработки программного обеспечения, чтобы разработчики не забыли о масштабируемости и безотказности функционирования, которым в перспективе будет отводиться особая роль, – отметил Хэнд. – Это особенно важно на этапе проектирования и первоначальной разработки, поскольку гарантирует работу создаваемых решений не только сейчас, но и через полгода, год и через два года. Если мы не хотим, чтобы какую-то часть кода пришлось переписывать, то должны убедиться в том, что учтены все будущие потребности».
SRE выступает в роли связующего звена и дипломата, который помогает сбалансировать потребности не только команд разработчиков, желающих создавать, тестировать и выпускать новые программы, функции, обновления и исправления как можно быстрее, но и заинтересованных лиц со стороны бизнеса, стремящихся добиться бессбойной работы всех продуктов и сервисов, с тем чтобы справиться с растущими потребностями и притязаниями клиентов.
«Роль SRE эволюционировала с учетом интересов двух этих разнородных групп, – подчеркнул Хэнд. – Зачастую противоречия между ними приходится устранять, даже если хотят они одного и того же: приложений, программного обеспечения и сервисов, отличающихся легкостью управления, а также высоким уровнем готовности, устойчивости и масштабируемости».
Дипломатия
Как разъясняет в своем блоге инженер по надежности компании Atlassian Патрик Хилл, SRE выступает посредником «в вековой борьбе между командами разработки и эксплуатации», разрешая споры о том, «что и когда можно запускать».
«Основная проблема заключается в следующем, – пояснил Хилл. – Разработчики хотят предлагать новые функции массам и радоваться достигнутому. Специалисты по обслуживанию, со своей стороны, желают убедиться в том, что эти функции ничего не нарушают. Исторически между ними ведется непримиримая борьба, в которой эксплуатирующие подразделения пытаются по возможности тормозить выпуск всего нового, а разработчики ищут способы обойти воздвигаемые на их пути барьеры».
«SRE призван исключить эти проблемы, сделать так, чтобы команды разработки и текущих операций заранее согласовывали порог ошибок, которые необходимо устранить перед запуском продукта», – пояснил Хилл.
«SRE как роль и символ перемен лучше подходит для зрелых организаций и крупных предприятий, – добавил Хэнд. – В небольших организациях у традиционных разработчиков программного обеспечения, инженеров по инфраструктуре, системных администраторов и другого эксплуатирующего персонала есть масса пересекающихся функций».
Этимология названия
«Название должности не имеет особого значения, – подчеркнул Хэнд. – Это может быть инженер DevOps, системный администратор, инженер по надежности систем, инженер по надежности сайтов. Важнее то, что скрывается за этой ролью. На небольших предприятиях каждый вынужден играть массу ролей, за надежность и устойчивость кода, а также за масштабируемость отвечают все, но в некоторых случаях рабочая нагрузка слишком велика, и тогда вводятся специальные выделенные роли».
«Для небольших организаций, у которых нет необходимых ресурсов, чтобы нанять специального SRE, неплохой временной мерой станет обучение уже имеющегося сотрудника процессам и процедурам, которые нужны при выполнении обязанностей системного администратора и повышения квалификации при использовании Chef, Ansible, Puppet и других инструментов автоматизации, – считает директор по набору ИТ-персонала кадрового агентства Mondo Стивен Зафарино. – Поскольку SRE требуют высоких зарплат, некоторые клиенты могут предложить профессиональную разработку кому-то из уже имеющихся у них сотрудников. Другой вариант – поискать фрилансера или консультанта, который даст нужный совет или примет участие в работе над конкретным проектом».
Хотя спрос на SRE сейчас и не слишком высок, в условиях более интенсивного перехода организаций в облако и получения ими программного обеспечения, сервисов и решений от независимых разработчиков эта роль становится все более распространенной и востребованной.
«Сегодня соответствующую зону ответственности зачастую разделяют между собой другие специалисты ИТ-службы – инженеры DevOps, программисты и системные администраторы, – подчеркнул Зафарино. – Открытые вакансии SRE заполнили лишь несколько наших клиентов. Но по мере интеграции концепции DevOps и принятия ее принципов спрос на SRE будет расти, а роль эта начнет принимать все более определенные очертания».
