Support analyst - что за зверь такой?

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

Давайте опишем некторые из задач, решение которых возлагается на такого человека.

Часть первая: Все ходы записаны

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

Почему один человек проверяет и дополняет документацию так же регулярно, как чистит зубы, а другой не станет этого делать ни за что и никогда? Очень просто. Не потому что лень. Потому что знания, опыт, помещённые в общедоступный файл, становятся общим достоянием. Для человека, привыкшего работать в одиночку, всегда тянуть одеяло на себя, на любом месте в первую очередь стремиться создать условия для своей незаменимости и неподотчётности, писать документацию - это всё равно что рубить сук, на котором сидишь. Он будет откладывать написание документов бесконечно, или даже станет саботировать эту задачу. И наоборот, профессионал всегда помнит, что он в этом проекте не навсегда. Когда-нибудь наступит день, когда он уйдёт. И никто не даст гарантий, что у него будет две недели, чтобы лично передать знания приемнику. Трагические случайности подстерегают нас в жизни на каждом шагу. В идеале, заказчику даже в таком печальном случае достаточно будет нанять нового, обстоятельного, дисциплинированного, просто среднестатистического человека, отнюдь не гения, дать ему прочесть документацию к проекту и уже спустя несколько дней получить для проекта тот же уровень поддержки, что был при его предшественнике. Memento mori - это не просто красивая фраза на латыни. Это один из признаков хорошего специалиста.


Почему хороший support analyst заинтересован в документировании проекта? Во-первых, потому что это записки на память самому себе. Если человек узнал что-то новое, касающееся проекта, то лучше это записать на будущее. Например, если периодически приходится исследовать проблему, связанную с некорректными записями в базе данных, по почему бы не записать на память используемые SQL запросы вместо того, чтобы каждый раз изобретать их заново? Это то, что по-английски называется knowledge base. Если у человека есть привычка регулярно вести записи, то по прошествии некоторого времени у него само собой получается описание системы. Можно дать прочесть свои записи более опытным коллегам, выслушать их замечания, уточнения, записать и их тоже. Возможно, вы что-то не поняли, упустили или ошибочно сочли несущественным. Во-вторых, поддержка приложения всегда связана с исследованием тех или иных инцидентов, проблем. Хорошо написанная документация к проекту даёт подсказку как локализовать проблему, каковы могут быть причины её возникновения, возможные способы решения. В-третьих, постоянно поддерживаемая в актуальном состоянии документация содержит прямое описание всех типичных проблем и то, как они были решены. Если большинство возникающих проблем систематизированы и описаны, то такую программу гораздо легче поддерживать. С другой стороны, имея такое описание, легче и исправлять вызывающий проблему дефект. И наоборот, в плохо документированном проекте каждый инцидент уникален, время и усилия, необходимые для его устранения, никогда невозможно оценить заранее. В-четвёртых, хорошо написанная и актуальная документация - это именно то, что нужно для введения в проект новых людей. Не надо отрываться от своих задач для проведения внепланового тренинга. Достаточно просто оправить человека читать документацию, а потом ответить на его вопросы, если таковые возникнут. В-пятых, документацию можно использовать для того, чтобы установить для всей проектной команды общее (адекватное) видение системы, единый порядок использования скриптов и утилит, общие для всех запреты и правила.

Что должно входить в документацию? Всё. Или, по крайней мере, всё то, что имеет смысл знать приемнику. Прежде всего, это архитектура системы. Что от чего зависит, что делает, по каким путям передаются данные, на какие подсистемы может появлиять отказ той или иной части программы. Во-вторых, какие внешние системы поставляют данные в программу, какие внешние системы зависят от вас. Для каждой из этих систем хорошо иметь номера телефонов и e-mail адреса соответствующих групп поддержки. Будет печально если программа не работает из-за того, что не получает от одного из внешних источников какие-то данные, а вы даже не можете определить этот источник, не можете связаться с соответствующей группой поддержки. Обязательно подлежит документированию вся информация о конфигурации, используемых настройках. Всегда существует вероятность отказа любого из серверов и придётся в срочном порядке менять вышедшие из строя части, переустанавливать операционную систему, переустанавливать программу, восстанавливать базу данных из последнего архива, сделанного в автоматическом режиме. Чем более полно описана процедура срочного восстановления системы, тем меньше времени потребуется на её выполнение, тем более меньше шансов второпях что-то пропустить или сделать не так. Наконец, даже если железо работает надёжно, есть вероятность того, что не в меру самонадеянный сотрудник что-нибудь сломает. Например, в моей практике были случаи, когда мне стирали crontab на главном сервере. Если бы я заблаговременно не позаботился о документировании этой таблицы, то имел бы очень большие проблемы. Далее, документированию подлежат все скрипты, используемые в проекте. Самое лучшее решение - это когда в начале каждого скрипта даётся ссылка URL на соответствующую web страницу (confluence page). На самой web странице указывается для чего используется этот скрипт, что он делает. Средствами HTML можно выделить, обратить внимание сотрудника на имеющиеся ограничения в использовании скрипта, а также предостережения. Далее идёт полное описание всех возможных аргументов в командной строке. И завершается web страница наиболее часто примерами использования этого скрипта. Бывает очень удобно иметь под рукой такое описание и выполнять ту или иную задачу, просто скопировав нужную команду с соответствующей web страницы. Если в проекте используется база данных и изучение возникающих проблем связано с анализом записей в ней, то нужно иметь такое описание используемой схемы, которое бы помогало быстрее решать проблему (в условиях неизбежного стресса), а не запутывало бы сотрудника ещё больше.

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

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


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

Ещё одной важной частью любого проекта является документ под названием function specification. Предоставить его должна команда, разработавшая данную программу. И этот документ должен обновляться при каждом релизе, который не только устраняет выявленные дефекты, но и меняет либо добавляет приложению новую функциональность. К сожалению, часто этот документ пишется либо формально, либо вообще отсутствует. Задачей function specification является описание бизнес-логики приложения. Простое перечисление клавиш и полей ввода - это не function specification, поскольку не отвечает на вопрос о тех алгоритмах и процедурах, которые стоят за этим внешним интерфейсом. Допустим, к вам обращается пользователь с вопросом: "Почему в этом поле программа показывает число 3.73? Я считаю, что здесь должно быть 5.70." Правильно написанный документ function specification позволяет быстро проследить всю цепочку вычислений, которая привела в результату 3.73, и показать её пользователю. Плохо написанный документ в таких случах оказывается бесполезен. И, чтобы ответить на вопрос пользователя, придётся заняться изучением исходного кода, сообщать ему свои догадки и предположения, а не то, что имели в виду сами программисты, когда писали этот код. Исследовать исходный код приложения всякий раз, когда у пользователей возникают подобные вопросы об его функционировании - согласитесь, это выглядит так же странно, как открывать капот всякий раз, когда вам нужно переключить передачу.

"Позвольте, товарищ! У меня все ходы записаны!!!"
(кадр из кинокартины "12 стульев")

Часть вторая: Простой инженер

В каждом проекте свои правила, своё расписание для выполнения поставленных задач, своя форма отчётности. Есть проекты, где разработчик неделями из дня в день занимается одной и той же задачей, и никто его не беспокоит. Есть проекты, где приходится гнаться за временем, чтобы успеть уложиться с очередным релизом в те сроки, чтобы были согласованы с заказчиком. Есть проекты, где каждый день начинается с короткого телекона. (Телеконференция, общее совещание с участием всех членов команды по телефону или по Skype.) Есть проекты, где значительная часть времени уходит на выполнение заявок от пользователей и оперативное решение возникающих технических проблем. Работы, что были запланированы заранее, выполняются в таком случае по остаточному принципу.

Я бы хотел рассказать о том, как именно проходил мой рабочий день в долговременном проекте, когда я несколько лет занимался удалённой поддержкой одного из ответственных приложений в крупном международном банке.


Подъём в 6 утра. Ночью прошли процедуры автоматической синхронизации базы данных приложения с внешними источниками. Были установлены новые продукты. Были удалены продукты, чей срок действия истёк. Отработали с вечера заготовленные скрипты, которые должны были создать новые сервисы. Всё это нужно проверить, удалённо подсоединившись к сети заказчика через VPN. Как сказал герой культовой киноленты: "Мой клиент желает знать все новости незамедлительно. Плохие - в особенности." Для проверки базы данных имеется ряд заранее заготовленных SQL запросов. Если найден какой-либо проблемный продукт или какая-либо другая некорректная запись, то с помощью специального атрибута следует её деактивировать и послать соответствующий запрос на исследование, либо команде сопровождения системы, откуда он был загружен, либо команде разработчиков на следующий уровень поддержки. До прихода пользователей на работу ещё 2-3 часа, один час до того как начнут автоматически запускаться сервисы. Этого вполне достаточно, чтобы найти проблемные продукты и даже выполнить небольшие изменения в конфигурации системы. Например, выполнить заготовленный с вечера план по балансировке нагрузки между серверами. Приходящие данные могут оказаться настолько некорректными, что даже сама процедура ночной синхронизации может завершиться с ошибкой. В этом случае придётся изучать логи, искать продукты, вызвавшие сбой, и выполнять ночную синхронизацию без них, но уже вручную. Времени на всё максимум полтора-два часа. К счастью, подобное случалось всего несколько раз за семь лет.

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

7:30 утра. На работе первым делом проверяем как прошёл процесс запуска сервисов. Вручную проверять статус почти тысячи Java процессов слишком долго. Для мониторинга процессов и серверов, где они запущены, заказчик предлагает системы Clarity и Clarion. Приятной особенностью Clarion является ещё и то, что эта система позволяет ещё и контролировать файлы огов на предмет появления определённых записей, свидетельстующих о проблемах. Если какой-либо процесс не стартовал или из-за некорректных данных превратился в процесс-зомби - ужасы бывают не только на телеэкране - то ещё есть полчаса-час, чтобы найти в базе эти данные, дективировать их и попробовать запустить процесс снова.


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

8:30 утра. Всё проверено. До того, как пользователи приступят к работе, есть ещё полчаса. Пишем им общее извещение о том, что всё проверено и система готова к работе. Теперь можно немного расслабиться и выпить чаю.


Две трети проблем с приложением выявляются в течении часа-двух после того, как пользователи приступают к работе. Проблемы обычно возникают с обменом с внешними источниками и получателями данных. Либо нам звонят и говорят, что от нас не поступают данные. Либо мы сами звоним и говорим, что не можем получить данные. В некоторых случаях, команда, отвечающая за какой-либо сервис, сама заранее рассылает уведомления о том, что с их программой возникла проблема и сообщают ожидаемое время восстановления работоспособности. В идеале support analyst мог бы решать все возникающие вопросы самостоятельно. Но на практике получается, что на изучение возникней проблемы у него есть максимум 10-15 минут. Поэтому он исследует либо типичные проблемы, либо проблемы, близкие к типичным для этого приложения. Если это какая-то новая проблема и с самого начала понятно, что за несколько минут её не решить, то лучше не геройствовать, а сразу передать её на следующий уровень поддержки, сопроводив всей имеющейся информацией о том, где эта проблемы возникла, при каких обстоятельствах и какие у вас имеются соображения на этот счёт. Ровно так же следует обращаться на следующий уровень поддержки, если одновременно возникло несколько проблем. Вы решаете только одну из задач. Остальные в это время решают ваши коллеги. Support analyst обязательно должен работать в команде. И вместе с тем, для пользователей системы именно он представляет всю команду, осуществляющую поддержку данного приложения. Он должен следить за выполнением всех задач, вовремя информировать пользователей о ходе устранения проблем, сообщать им ожидаемое время готовности. Если у какого-либо пользователя возникло ощущение что о его проблеме забыли, никто над ней не работает, то это в первую очередь просчёт самого support analyst, подводящего таким образом свою команду. Разумеется, очень желательно впоследствии обсудить с коллегами случившиеся инциденты. Что послужило их причиной, как в будущем бороться с аналогичными проблемами.

Итак, приложение стартовало и работает уже несколько часов. Следующая задача - это его непрерывный мониторинг на протяжении всего рабочего дня. В общем случае, следить нужно за состоянием сети (физической доступностью всех серверов), наличием свободной памяти и свободного места на локальных и сетевых дисках у этих серверов, работой всех процессов приложения, за появлением сообщений об ошибках в лог файлах. Для мониторинга всего этого можно использовать те же программы Clarity и Clarion, которые использовались во время утренней проверки. С точки зрения пользователя эти системы можно охарактиризовать как большая зелёная лампочка, весь день показываемая в углу на экране вашего компьютера. Если в какой-то момент лампочка поменяла свой свет на красный, то это значит, что где-то среди сотен процессов и десятков серверов возникла проблема. Конкретный источник проблемы можно обнаружить, спустившись по иерархии узлов в окне приложения. Аналогичная программа есть в MS Windows. Есть и open source аналоги. В некоторых других проектах я пользовался системой мониторинга, которая помимо световой индикации могла ещё автоматически посылать сообщения на сотовый телефон или пейджер. В данном проекте программа дополнительно делала новую запись на соответствующем техническом чате. Например, если Clarion обнаруживал слово OutOfMemory лог файле для stdout какого-либо Java процесса, то команда поддержки узнавала об этом практически тут же. С информацией что это за сервис и на каком именно сервере он запущен. Это гораздо лучше, чем узнавать о проблеме лишь тогда, когда вам на неё укажут пользователи приложения. Хорошо бы приступать к решению проблем ещё до того, как они начнут менать работе пользователей.

Большое приложение, критическое важное для бизнеса заказчика, сопровождается значительным количеством вспомогательных скриптов, которые можно разбить на четыре основных группы. Первая группа - это скрипты для проверки и мониторинга. Например, в процессе проверки базы данных мы обнаруживаем ранее не встречавшийся вид дефектного продукта. Имеющиеся скрипты, которые мы запускаем для проверки базы данных каждое утро, его не обнаруживают. После консультации с программистами создаём новый скрипт, который запускает соответствующий SQL запрос и докладывает в чате о появлении дефектных продуктов такого типа, если они будут обнаружены. Другой пример мониторинга - это скрипты, постоянно сканирующие лог файлы и делающие нетривиальную проверку сразу по нескольким соседним строкам. Неожиданно востребованной оказалась хронология о действиях самих пользователей. Например, вопрос о том, кто на этой неделе поменял настройки для данного продукта, что именно и в какой очерёдности он менял. (То есть, вопросы кто виноват и что сделать, чтобы вернуться к прежним настройкам, могли решаться достаточно оперативно.) Вторая группа скриптов предназначена для генерации отчётов. В нашем случае программа рассылала несколько десятков отчётов в разной периодичностью: ежедневно, еженедельно, ежемесячно. Большинство из них черпало информацию из базы данных: какие операции были совершены с помошью программы, сколько раз, в каком объёме. И так для каждого типа продуктов, для каждого пользователя, и т.д. Излишне говорить о том, что пользователи постоянно просили создать новые виды автоматических отчётов, либо поменять структуру уже имеющихся. Третья группа скриптов - это заготовки, помогающие быстрее изучать возникающие проблемы. Например, это может быть дежурный набор скриптов, делающих SQL запросы, которые вы ещё не успели оформить как хранимые процедуры или специальные представления. Последняя, четвертая группа скриптов помогает упростить и сделать более надёжной процедуру установки релизов и реконфигурацию приложения. Например, если какая-либо последовательность команд из раза в раз применяется в ходе реконфигурации, то почему бы не оформить её в виде скрипта, который можно запустить одной командной строкой? Во-первых, это позволяет сохранить последовательность, подтвердившую свою полезность и правильность, для использования в дальнейшем. Во-вторых, сокращение количества команд, требующих ручного ввода, упрощает план релиза, ускоряет сам релиз, а также уменьшает вероятность случайной ошибки, опечатки.

Сложное распределённое приложение, где группа однотипных сервисов обрабатывает несколько параллельных потоков данных - это живой организм. Каждый день приходят новые продукты. Каждый день уходят продукты, чей срок действия истёк. И не всегда при этом получается равномерное распределение. Бывает необходимо переназначить обработку продукта на другой сервис, бывает необходимо перенести сам сервис на другой сервер, чтобы обеспечить равномерное распределение нагрузки и примерно одинаковую скорость обработки. Также сам Java процесс может иметь малую нагрузку, либо быть близким к исчерпанию максимального объёма выделенной памяти, определяемой аргументом Xmx в командной строке. Процесс может быть 32-битным или 64-битным. Может потребоваться создать новые сервисы, чтобы уменьшить нагрузку на уже имеющимся. Может поменяться окружение. Например, внешний источник, откуда вы черпаете данные, может поменять свой адрес и номер порта. В любом случае, задача подготовить реконфигурацию программы таким образом, чтобы её выполнение не сказалось на работе программы, не вызвало недовольство пользователей на следующее утро - это обычное занятие к концу рабочего дня. Общее правило всегда писать подробнейший implementation plan и максимально использовать уже имеющиеся и многократно проверенные наработки оставалось неизменным за все годы, пока я участвовал в этом проекте.

Ну и последнее. Выполнение заранее написанных implementation plan либо утром/вечером в рабочий день, либо в выходные. В субботу лучше, поскольку можно не спешить - впереди два дня, а не два часа - всё тщательно проверить и перепроверить.

"Он кто? Инженеришка рядовой. И всё.
Ну что у него за жизнь?
Утром - на работу. Вечером - с работы.
Дома жена, дети сопливые."
(кадр из кинокартины "Джентльмены удачи")