Мальчики, которые чинят компьютеры: что на самом деле делают инженеры сопровождения

Инженеры сопровождения — это специалисты, которые следят за стабильной работой IT-систем. Но часто их путают с техподдержкой, системными администраторами, DevOps-специалистами, а иногда и с тестировщиками. 

Тема кажется очевидной, но зачем тогда писать статью? В профессии я 4 года и все это время сталкиваюсь с большим количеством непонимания, какие задачи выполняют инженеры сопровождения. Периодически я вижу негатив от команды разработки, которая считает, что мы препятствуем работе, а от бизнеса получаю задачи, не попадающие в мою зону ответственности. 

В статье я поделюсь главными стереотипами о работе инженеров сопровождения со стороны разработки и бизнеса, а также расскажу, что на самом деле входит в наши обязанности, а чем мы заниматься точно не должны. Статья будет полезна специалистам, которым интересно разбираться в нюансах работы своих коллег и расширить кругозор в IT.

Коротко обо мне: я Кирилл Назаров — инженер сопровождения в Outlines Tech. Начинал свой путь в IT-поддержке, потом прокачался как инженер в игровой студии, а сейчас работаю на банковском проекте. 

Стереотипы и мифы: инженеры сопровождения — не «мальчики, которые чинят компьютеры»

Бизнес часто воспринимает сопровождение как мальчиков, которые чинят поломки в системе. Да, иногда приходится что-то чинить «руками», но залезть в код и моментально исправить ошибку, как разработчики, мы не всегда можем. Наша задача – зарегистрировать ошибку, найти способ ее исправить, а уже затем передать в разработку. 

Нас можно назвать командой «последнего рубежа» – мы имеем суверенное право отказаться от любой новой фичи, если она работает плохо, и сказать: «ребят, переделывайте». Например, на прошлой работе у клиента программа неверно рассчитывала суммы в юридических документах, причем умноженные на 10 или 15. Мы поймали этот баг в последний момент, когда разработчики «похлопали себя по плечу» и хотели закрыть задачу. Пришлось их звать обратно и ночью сидеть все исправлять. 

В глазах разработки мы вообще вредные люди, которые не дают закрывать задачи. Как будто мы такие вот злые дяди сидим и «вставляем палки в колеса». Но цель у нас общая – обеспечить стабильную работу системы. Только разработчики хотят побольше всего реализовать, а нам важно, чтобы все было качественно. 

Чем инженеры сопровождения точно не занимаются (иногда) 

Самое больное для меня и с чем я больше точно не хочу работать – это тестирование. В небольших командах приходится самим заниматься ручным тестированием, потому что не хватает специалистов, а задачи закрывать надо. Сейчас мы проводим минимальные тесты только перед релизом, например, Smoke-тесты, чтобы ответить себе на вопросы: «А вот то, что мы устанавливаем сейчас в продакшн, оно вообще будет работать или нет?». Это часть процесса принятия решения. 

Разработка тоже не входит в наши обязанности. Нам не нужно знать, как работает логика системы на уровне кода. Наша задача – следить за уже работающей системой, а не создавать и тестировать ее с нуля. А еще инженеры сопровождения не должны разбираться в бизнес-логике приложения.

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

Например, в одной из систем много логики было реализовано на Microsoft SQL, а задачи связаны с процедурами и функциями. Они лежали внутри базы данных в открытом виде. И часто к нам приходили пользователи с вопросами: «У меня там некорректно рассчиталась такая-то сумма, некорректно рассчитался такой-то коэффициент». Единственный способ найти причину – залезть внутрь кода функций и разобраться, откуда что появилось. И только потом уже прийти к разработчикам и спросить: а как это все это можно починить.

Второй повод использовать инструменты разработчика – ошибки в интеграционных взаимодействиях, например, связанные с RabbitMQ. Они возникают часто: сторонняя система ломается и отправляет неверный запрос, а у нас выскакивают ошибки. Тогда мы вручную пишем этот запрос и смотрим, что вернет система, с которой мы интегрируемся. 

Кстати, мой коллега SRE-инженер Евгений Корнеев собрал интересную подборку книг для расширения кругозора в IT и развития в сфере. 

Техподдержка и инженеры сопровождения: а есть ли разница?

Очень часто инженеров сопровождения и техподдержку путают. Практически постоянно. Мы можем обеспечивать поддержку в рамках того, что это наша система и мы знаем как она работает. Но разница в зонах ответственности – техподдержка решает точечные запросы конкретных пользователей, а мы копаем глубже и разбираемся как все работает внутри. 

На мой взгляд, путаница может возникать по двум причинам:

Первая – отсутствие нормальной поддержки пользователей системы. Когда нет телефона хелпдеска, который может внятно и вдумчиво ответить пользователю на вопрос, то первая линия поддержки переводит к нам.

Вторая – отсутствие нормальных инструментов администрирования для поддержки пользователей. Например, сейчас у меня в работе система базы знаний. Основная проблема – эта система при интеграции с другими не учитывает настройки уровней доступа для разных пользователей. Одна из групп пользователей вообще не получает доступы. В разработку проблему пока не берут, потому что нужно закрывать более ранние дефекты. В итоге нам приходится общаться с пользователями, а затем залезать в систему и «руками» выдавать доступы. 

Взболтать, но не смешивать: как DevOps-практики меняют роль инженеров сопровождения 

Еще 20 лет назад инженеров сопровождения не существовало, это были, по сути, системные администраторы. Сегодня они занимаются тем, что раньше называлось «IT-поддержка и сервис». А DevOps-практика предполагает, что ты и разработчик, и инженер одновременно. Задача DevOps в том, чтобы написать инструменты для системы, с которыми дальше будет работать инженер сопровождения. 

Сейчас работа инженера сопровождения начинает приближаться по функционалу к DevOps, а специалисты этого профиля больше уходят в инженерную область. Соответственно, рынок и от сопровождения начинает требовать компетенции DevOps-специалистов, а много вакансий уже прописывается как «Инженер сопровождения/DevOps». Возникла даже новая роль – System Reliability Engineer или SRE, которая начинает приближаться к классическому DevOps.  

Заключение: так кто же все-таки такие эти инженеры сопровождения

Наша главная задача – обеспечить стабильную и корректную работу сервисов. Мы, в каком-то смысле, мост между разработкой, бизнесом и пользователями. И последний рубеж перед релизом, поэтому существуем отдельно ото всех остальных участников команды. 

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

А как в вашей компании поделены задачи между инженерами сопровождения, разработчиками и тестировщиками? Интересно обсудить в комментариях опыт других команд.