Как мы отрабатываем аварии в банке
Меня зовут Павел, и я работаю в банке архитектором автоматизированных систем. В мои задачи входит поддержание работоспособности нескольких систем, связанных с корпоративным кредитованием. К счастью, здесь, если сравнивать с моим предыдущим местом работы, всё более-менее спокойно. Если какие-то поломки и происходят, то отнюдь не в результате фишинга или DDoS-атак. Хотя, конечно, такое у нас в банке тоже случается: только за три месяца 2022 года в России было зарегистрировано более семи тысяч атак на финансовые учреждения. Их предотвращением и устранением последствий у нас занимаются отдельные команды.
Моя же сфера касается в основном внутренних сервисов банка, а до них добраться на порядок сложнее, чем до внешних. И проблемы чаще появляются из-за нового релиза, а не из-за чьей-то направленной атаки. Да, так бывает, что что-то ломается после своих же апдейтов, и приходится налаживать.
Рутина
Налаживать после обновлений — нормальный процесс. Когда происходит релиз, надо быть готовыми к тому, что что-то пойдёт не так. Придётся разбираться, где и в чём ошибка и как её можно устранить. Это неотъемлемая часть работы, и надо быть изначально таким человеком, который не стрессует и не паникует, когда происходит сбой в ПО или на стороне инфраструктуры, а с интересом разбирается, в чём там затык, почему не работает и как наладить систему самостоятельно.
Или же оперативно ищет тех, кто поможет, если случится какая-то специфическая поломка. Таких нестандартных случаев в моей практике раз-два — и обчёлся: в 90% случаев я понимаю, что, где, как устроено и как восстановить работоспособность программ. А иногда и железа.
В роли главного архитектора нужно быть универсалом, который работает и руками, и головой, если надо, и программку напишет, и как устроен, например, сервер тоже хорошо себе представляет. Без опыта многолетней практики системного администрирования корпоративных сервисов, техподдержки, интереса к разработке невозможно было бы выполнять весь объём задач, за который я отвечаю.
А ещё важно прокачать софт-скиллы, уметь общаться и с руководством, и с командой и понимать интересы бизнеса. Получается, что ты такой «многогранный человек», который одинаково хорошо понимает и людей, и железо, и ПО.
Чем занимается главный архитектор автоматизированных систем?
В настоящее время я занимаюсь проектированием и эксплуатацией двух внутренних систем, связанных с кредитованием юридических лиц. Мы с коллегами настраиваем и обслуживаем программное обеспечение. А если что-то там ломается, то исправляем.
Мы сфокусированы главным образом на внутренних сервисах, где основными пользователями являются сотрудники банка. С внешними сервисами приходится иметь дело постольку-поскольку. В системе у нас зарегистрировано несколько тысяч сотрудников, и наша задача — сделать их работу максимально простой и удобной.
Аварии в моих системах чаще всего происходят по двум причинам: либо в результате релизов — еженедельного обновления ПО, либо из-за проблем в инфраструктуре: полетели сеть, серверы и т. д. Техподдержка состоит из нескольких линий. Первая линия помогает разобраться с простыми вопросами — таких 90%, остальные идут в работу на вторую и третью линию. А чтобы находить ошибки до того, как они станут авариями, мы привлекаем в помощь сотрудников из других подразделений.
Когда происходит какая-то авария, ребята из технической поддержки прикладного ПО, где идёт мониторинг систем, первым делом приходят к командам и архитекторам или пишут в аварийный чат, и мы вместе устраняем неполадки. Если же мы не справляемся, то всегда можем обратиться к коллегам из инфраструктуры. Но, повторюсь, на 90% со всеми задачами мы справляемся самостоятельно и знаем свою платформу и по программной, и по инфраструктурной части практически от и до.
Телефон спасения, или Как работает местный 911
Конечно, аварии случаются. Вот, например, пришёл сотрудник на работу, а у него почта не работает. Или заявки не отправляются. Или что-то ещё, и надо срочно выяснить, в чём дело, и починить сервис. В большинстве случаев сотруднику неинтересно, из-за чего там что-то сломалось. Ему важно как можно скорее получить привычные инструменты в рабочем состоянии.
Для разрешения всевозможных вопросов по технической части у нас работает Служба поддержки пользователей (СПП). Сотрудники могут обратиться за помощью по телефону (как внешнему, так и внутреннему) или отправить заявку через форму на портале поддержки пользователей. Когда человек знает, к кому обратиться, он может и прийти лично, но это скорее исключение. Большинство же сотрудников при подаче заявки пользуется или телефоном, или электронной почтой.
Люди, которые отвечают на звонки в Службе поддержки пользователей, имеют специальную подготовку — не только техническую, но и психологическую, т. е. знают, как оставаться эмоционально уравновешенными. Мы им готовим скрипты для работы по наиболее частым вопросам, и, как правило, 90% заявок не уходит дальше первой линии поддержки: стандартных процедур оказывается достаточно для решения львиной части проблем.
Изредка, но бывает, что в Службу поддержки пользователей может позвонить кто-нибудь из высокопоставленных сотрудников банка. Для таких ситуаций есть специально обученные люди, которые берут улаживание вопросов на себя. Они, как правило, в курсе, кто им может позвонить и как себя вести, могут поговорить с VIP-сотрудником так, чтобы он успокоился и понятно объяснил, в чём проблема.
В моей практике бывало, что вице-президент связывался напрямую с инженером, когда знал, в зоне чьей ответственности проблема. В таких случаях важны выдержка и равновесие: паника ничего не решит, надо спокойно пообщаться, как можно быстрее устранить поломку или найти обходное решение. А дальше разбираться, из-за чего она произошла.
Привычки и экономическая целесообразность
Сейчас модно говорить о создании сервисов, работающих по принципу «одного окна». И мы к этому идём, хотя всегда остаются исключения. Вот вам пример. Все сотрудники отправляют заявки через единую форму на портале поддержки пользователей. А у кого-то сломался компьютер. Всё, доступа к Интернету нет, а доступ с личного смартфона на корпоративные сервисы ограничен. Единственный вариант — это либо звонить в СПП, либо лично обратиться к специалистам, если человек знает, в чьей это компетенции.
Вообще, конечно, это удобно, если бы все заявки сортировались и автоматически перенаправлялись тому специалисту, который за этот вопрос отвечает. Но в целом у нас и так очень многое автоматизировано в плане обращений. А какие-то нестандартные вопросы проще и дешевле разбирать вручную.
Ещё отмечу: всякая унификация имеет и свои слабые места. На прошлом месте работы мы предложили руководству внедрить IP-телефонию, закупить гарнитуры: это же удобно, никаких проводов, мобильнее и экономичнее, если сравнивать со стоимостью телефонных аппаратов. Но инициативу не поддержали: оказалось, что многие работники консервативны, им просто нравится говорить по телефону и при этом держать трубку. По-моему, у Microsoft на заре развития UC было исследование на эту тему: 30% сотрудников ни в какую не хотят пользоваться гарнитурой, именно поэтому в продаже столько настольных аппаратов для систем объединённых коммуникаций.
«Сходите-ка чайку попить, а мы пока всё починим»
У нас три линии техподдержки. Служба поддержки пользователей принимает звонки и разбирает заявки, которые падают на почту и портал. Это первая линия, она спасает инженеров от решения рутинных задач, разруливая те вопросы, которые продвинутые пользователи могут решить самостоятельно. На второй линии проблемы, которые требуют вмешательства разработчиков, заявки оформляют в виде задач в системе Jira. Мы как третья линия поддержки помогаем специалистам первой и второй: даём им алгоритмы работы в определённых ситуациях, инструктируем, что делать в нестандартных случаях. Всё это записываем в базу знаний в Confluence.
Вот звонит, например, человек в панике, что у него какой-то сервис, который ему срочно нужен, но он не работает. В таких случаях бывает важнее в первую очередь не столько поскорее починить «заартачившуюся» программу, сколько снять напряжение и тревожность с обратившегося сотрудника. Знание базовых психологических приёмов в таких ситуациях очень выручает: понизить голос, говорить помедленнее, самим быть спокойными. Иногда просто вот такого разговора, который поможет сменить ракурс восприятия проблемы, оказывается достаточно, чтобы специалист вернулся к адекватному состоянию и не воспринимал слишком остро то, что что-то пошло не по плану.
А вот с тревожным сотрудником техподдержка не может нянчиться до бесконечности: у каждого есть свои регламенты, оптимальное время приёма/выполнения заявки. И иногда нужно дать понять человеку: чем дольше мы общаемся, тем позже я приступлю к устранению поломки.
«Ты мне маякни, если что…»
Для того чтобы сотрудники были психологически готовы к «сюрпризам», мы за день предупреждаем, что ставим новый релиз системы. Когда что-то работает не так, нам об этом до того, как это будет массовым инцидентом, сообщают система мониторинга или «любимые пользователи». «Любимые пользователи» — это сотрудники, которых мы напрямую просим понаблюдать за адекватностью работы ПО. И если что-то в системе им покажется подозрительным, то они нам об этом по-дружески, без лишнего шума сообщают. Можно сказать, это добровольные «тестировщики», которые помогают нам вовремя обнаружить дефект до того, как проблема выйдет на публичный уровень. И это действительно выручает: заметить мелочь до того, как это заметил кто-то ещё, и предупредить, пока это не привело к аварии.
Стать «любимым пользователем» может и опытный, и новый сотрудник. Главное — быть внимательными, доброжелательными и хотеть помочь команде разработки или технической поддержки. Чаще всего такие связи появляются при личных знакомствах, например, на обеде или общих мероприятиях. Поэтому в век удалённой работы личные коммуникации очень важны.
О компетенциях и командной работе
Когда речь идёт о пополнении моей команды, то я в первую очередь обращаю внимание на три фактора: наличие у специалиста фундаментальной подготовки, его желание развиваться и осваивать новое, и ещё большое значение имеет фактор психологической совместимости.
Очень часто можно встретить специалистов, которые освоили только какую-то часть знаний, могут работать по инструкции, а любое отклонение от шаблонов вводит их в ступор. Т. е. приходят люди на хорошую должность с отличной зарплатой, а случись какая-то нештатная ситуация — они понятия не имеют, что делать. Это раньше можно было изучить какую-то тему и сидеть на ней годами. Сегодня такой подход заведомо провален. Необходимо постоянно пополнять и обновлять свою личную базу знаний.
Например, архитектору просто никуда без понимания базовых корпоративных инфраструктурных сервисов. Пусть не на детальном уровне, но такой специалист должен представлять, как работает корпоративная сеть, как настраивается сервер и как он устроен, что такое виртуализация и принципы её работы, обязательно знание базовых сервисов Active Directory, DNS, DHCP, почтовой системы и, конечно же, сертификатов: без них сегодня никуда, надо знать несколько скриптовых языков, уметь программировать и, самое главное, логически мыслить.
Т. е. в этой профессии важно иметь знания как по части системного администрирования, так и по части разработки. Иногда может понадобиться самому написать программку, чтобы автоматизировать какой-то процесс. Да и в целом это позволяет лучше понимать, как устроен процесс разработки софта, и находить общий язык с разработчиками. А это совершенно необходимо для устранения аварий: они нередко происходят из-за ошибок в коде, и исправлять их приходится тому разработчику, по чьей вине «всё легло». Однако не всегда он сам с лёту может обнаружить, где именно допущена ошибка, поэтому компетенции по части разработки точно не будут лишними: подсказать сотруднику, направить.
В особо сложных случаях мы устраиваем мозговой штурм: сообща решаем, как действовать в нештатной ситуации. Круто выручает возможность написать во внутренний телеграм-канал коллегам (там у нас всё есть: и разработчики, и тестировщики, и DevOps, и т. д.) и запросить консультацию экспертов по теме.
«Посторонний не поймёт, а для нас — зацепочки…»
Отгулы, больничный, отпуск… Иногда отсутствие коллеги на рабочем месте или его замена может застопорить процесс решения проблемы. Для того чтобы другим сотрудникам было понятно, как решать вопрос, мы ведём базу знаний в Confluence. По тем моментам, которые там зафиксированы, профильному эксперту можно понять, как что устроено, и решить вопрос. Всегда стараюсь добавить полезную информацию в Confluence, чтобы в случае необходимости специалист мог добыть необходимые знания. И вообще у нас в компании очень развита вот эта культура обмена знаниями: если что-то нужно подсказать, то я никогда не откажусь рассказать человеку о нюансах, и другие поступают так же. И вот эта традиция взаимного обогащения информацией, она ценна. Что касается каких-то оперативных вещей, то для себя я их записываю в OneNote: скрипты, команды, личные заметки для сохранения контекста по задаче и т. п. Часто после этого самое полезное я просто копирую в Confluence для общего доступа.
По вопросам обучения можно ещё обращаться на наш портал «Импульс»: там собраны разные внутренние курсы для специалистов. И если человеку не хватает каких-то компетенций, то руководство может поставить ему в задачи послушать эксперта.
«Больше аварий — больше опыта», или Как из техподдержки вырасти до SRE
На сложных нагруженных проектах в больших командах есть отдельный специалист. Это разработчик, который отвечает за бесперебойную работу системы, — SRE (Site Reliability Engineer). Эта должность предполагает постоянный мониторинг работы платформы и недопущение каких-либо серьёзных факапов в её функционировании. По идее это разработчики, которые предотвращают и устраняют аварии. По своей сути они очень близки к DevOps, но если DevOps — это больше про администрирование, то SRE обязан иметь знания в разработке, потому что «укрощение» сложных систем как раз-таки связано с умением читать чужой код и находить ошибки, которых сам разработчик, может быть, и не видит. И уметь писать какие-то программы для автоматизации каких-нибудь процессов тоже пригодится.
Откуда берутся SRE? Это высококлассные специалисты, которые вырастают в крупных ИТ-компаниях. Конечно, на просторах Интернета легко найти массу курсов платных и бесплатных по этой теме, но реальные специалисты — это те, кто имеет огромный бэкграунд разработки и эксплуатации ПО. Такие специалисты нужны и в банках, и в частных компаниях, и в крупных госорганизациях.
Чаще всего хорошие Site Reliability Engineers вырастают из техподдержки. Это то, с чего стоит начинать. Только в банковском секторе по миру — около 2 000 вакансий именно в техподдержке. Hо тут важно не просто просиживать штаны, а по максимуму использовать возможности для получения знаний: общаться с коллегами, с руководством, всё время что-то изучать. Потом уже можно податься в системное администрирование или DevOps. Эти знания в любом случае пригодятся, как и навыки разработки. И вот уже следующая ступень компетенций — это SRE, такой «универсальный солдат», который умеет и с руководством коммуницировать, и в разработке понимает, и по части системного администрирования может проблемы решить.
Книжечки
А чтобы было интереснее учиться, вот мой совет по литературе, которую стоит почитать по данному направлению. Эти книги содержат реальный практический опыт, здесь не так много философии, зато масса практических знаний. Короче, Must read.
Практика системного и сетевого администрирования. ISBN 978–5–6040043–1–9.
Site Reliability Engineering. Надёжность и безотказность, как в Google. ISBN 978–5–4461–0976–0.
Release it! Проектирование и дизайн ПО для тех, кому не всё равно. ISBN 978–5–4461–2020–8.
System Design. Подготовка к сложному интервью. ISBN 978–5–4461–1816–8.
