Привет! В прошлой статье мы рассказывали о 7 из 14 кейсов, с которыми столкнулись только за последний год, работая в саппорте на зарубежном проекте. Напомним, уже 9 лет мы сотрудничаем с клиентом из Великобритании, который предоставляет ПО для госпиталей и обеспечивает целый ряд шагов бизнес-процесса. Предысторию проекта и то, как работа в саппорте помогает развивать IT-продукт и повышать квалификацию, описали здесь.
Сегодня мы продолжаем рассказ о “татуировках” и выводах, основанных на практическом опыте саппорта. В предыдущей статье шла речь про безопасность, бэкапы, взаимодействие с внешними системами, про документацию и бизнес-процессы. В этой рассмотрим виртуализацию, политику хранения данных, логирование, работу с большими данными и прочее.
Надеемся, эти кейсы помогут более комплексно посмотреть на разработку, задуматься о том, как создаваемый продукт будет эксплуатироваться пользователями. В свою очередь, это помогает лучше понимать бизнес-процессы клиентов, тем самым дополнительно увеличивая потенциал разработчика и предоставляя ему больше возможностей для роста.
Татуировка 8: практически невозможно досконально знать большую систему
Мы работали с этой системой более 9 лет и думали, что знаем, как можно её использовать. Ведь шаги бизнес-процесса очень простые:
доктор диктует информацию о пациенте,
аудиофайл переводится в текст и создается документ, в котором есть информация о диагнозе пациента,
доктор утверждает этот файл,
после утверждения информация доставляется в нужные интеграционные системы, доктору, пациенту.
Казалось, что может быть проще и логичнее?
Когда мы добавляли систему контрольных точек для проверки корректности бизнес-процесса, в числе проверок мы добавили следующую: “Письмо утверждено врачом, имеет цифровую подпись”. При неправильно настроенном бизнес-процессе этот алгоритм мог не соблюдаться, и мы считали это ошибкой.
После того, как мы ввели эту проверку, в одном из госпиталей мы внезапно обнаружили ошибку: было много писем без подписи доктора. Мы были рады, ведь это казалось очевидной ошибкой. Гордые собой, мы пошли к госпиталю и попросили их исправить, сказали, кто сделал неверный бизнес-процесс: в админке у нас есть логирование того, кто, когда и что выполнял.
Ответ госпиталя нас озадачил: “Все настроено верно, там подписи доктора быть не должно”. После получения ответа мы решили уточнить, почему такое может быть. Детальный ответ госпиталя нас очень удивил. В чем оказался “фокус” данного кейса.
Наша система имеет интеграции с 14 различными внешними системами, которые распространены в Великобритании. Одна из них – система с информацией о больных сахарным диабетом. Написание той интеграции мы до сих пор вспоминаем, она не менялась 10 лет, API был очень неудобный. Также довольно много работы было во время тестирования этой системы, потому что тестовый сервер было сложно получить.
Госпиталь имел еще одну систему в отделении, параллельную нашей. В Великобритании это норма, там разные отделения в одном госпитале могут пользоваться разными интеграционными системами. И разработчики той “параллельной” системы не имели интеграции с системой для больных сахарным диабетом. И когда их попросили доработать систему, эту интеграцию оценили довольно дорого, поскольку система была очень “тяжелая”.
Что сделал госпиталь? Работы из этой параллельной системы, которые были утверждены там, они экспортировали в нашу систему. Также они настроили бизнес-процесс на экспорт работ в систему о больных сахарным диабетом. И экспортировали информацию о пациентах через нашу систему. Но при этом отказались от доработки параллельной системы.
Именно поэтому бизнес-процесс в “нашей” системе не имел утверждения доктора.
Вывод: если у вас система большая, вы можете надеяться, что знаете основной бизнес-процесс. Но пользователи системы могут начать использовать вашу систему так, что вы будете сильно удивлены, когда об этом узнаете. И при этом все может еще работать, как надо.
Татуировка 9: логируйте, не надо верить пользователям
В один прекрасный день к нам в саппорт пришел запрос – текст с диагнозом пациента после объединения с шаблоном документа стал “удваиваться”.
Этот запрос был необычным. В шаблоне было все хорошо, других подобных запросов не поступало. Причины были неясны. К счастью, в админке мы в свое время добавили логирование, которое не только логирует действия пользователя, но на уровне БД сохраняет все старые версии шаблонов. Оказалось, секретарь изменил шаблон документа, потому что обновился контактный телефон. Хотя корректнее сказать, что он хотел изменить шаблон, но это ему не удалось. Он просто добавил в шаблон еще один.
Предположим, старый шаблон с тегами для подстановки данных, логотипами и т.д. имел форму документа А. Новый шаблон с тегами и всем остальным имел форму документа B. Логично ожидать, что после изменения шаблон будет иметь форму B, но из-за неверных действий пользователя он стал иметь форму BA, т.е. пользователь вставил в начало шаблона новые данные и не удалил старые. Через 12 минут он понял, что ошибся, и сделал корректный шаблон с формой B, удалив форму А. И никому не сказал, что сделал ошибку.
Только за эти 12 минут неверный шаблон был несколько раз использован. Это объяснило, почему не было новых запросов – шаблон уже исправили. Мы предоставили госпиталю доказательства с указанием того, что произошло и кто сделал ошибку. Госпиталю такого объяснения было достаточно.
Вывод: всегда надо логировать любое изменение конфигурации не только в админке, но и через триггеры на уровне БД. Это необходимо, чтобы иметь возможность отслеживать изменения в результате прямых запросов к БД. К сожалению, не все это делают.
Татуировка 10: никогда не вредно спросить, даже если изначально клиент говорит “нельзя”
Работа саппорта становится проще, когда есть хотя бы частичный доступ к базе данных. Но в нашем случае была большая проблема – персональные данные. К ним у нас не должно было быть доступа.
Казалось бы, это “блокер” – раз есть конфиденциальные данные, то никакого доступа быть не может. Но в БД есть много не конфиденциальных данных – врачи, структура госпиталя, шаблоны документов, история обработки аудиофайла и многое другое. Часто конфиденциальные данные находятся лишь в нескольких таблицах. И мы предложили клиенту сделать репликацию БД без полей с конфиденциальными данными.
Также это решало еще одну бизнес-задачу – получение статистических отчетов. Часто менеджменту госпиталя нужно знать, сколько пациентов пришло за день, сколько документов было подписано цифровой подписью за день, сколько аудиофайлов было обработано секретарем и т.д.
После обсуждения с клиентом и доказательства того, что в реплицированной БД не будет конфиденциальных данных, это было реализовано. И теперь, в дополнение к более легкой работе на саппорте, мы имеем решения для статистических отчетов. И эти отчеты не могут повлиять на основную БД с точки зрения нагрузки на SQL-сервер, потому что находятся на другой физической машине.
Вывод: часто клиент говорит “нельзя”, потому что не знает о возможном способе решения. Поэтому когда вы слышите от клиента “нельзя”, уточните причину и можно ли найти вариант, который устраивает всех.
Татуировка 11: легко написать систему, которая работает месяц, тяжелее – систему, которая работает 10 лет. За это время изменится очень многое – и не только технологии
Статистика говорит о том, что среднее время работы программистов в ИТ-компаниях – от года до трех лет. Если мы говорим о разработке систем в течение 10 лет, надо быть готовым к тому, что будет несколько “поколений” программистов. Но также надо учитывать, что в системах, которые разработаны или разрабатываются другими компаниями, происходит то же самое. И часто новые поколения приносят с собой новую философию и новые положительные вещи. Все было бы хорошо, если бы не один факт – смена поколения ведет к “обрезанию” коммуникационных связей.
Как-то мы анализировали интеграцию с одной внешней системой, предназначенной для обработки результатов приема пациента. Суть довольно проста – она формирует сообщение Hl7 (стандарт в Великобритании), и мы отправляем его в интеграционную систему. В ответ мы получаем результат обработки и логируем его.
Время обработки сообщения внешней системой было стабильным – от 200 до 400 мс. Для области медицины это нормальный показатель. Мы добавили в систему отчетности графики с гистограммой времени обработки запросов внешней системой и получали их каждую неделю. Все было хорошо, распределение времени обработки было одним из классических.
В один прекрасный день пришел нестандартный график. Появилось еще одно распределение – время обработки от 0 до 50 мс. Мы удивились и начали исследовать этот вопрос.
Оказалось, что внешняя система добавила валидацию данных и сделала отчество пациента обязательным полем, никого не оповестив об этом. Это объясняло быстрый ответ системы - данные не проходили валидацию, и поэтому не происходила запись на их стороне. IT-служба госпиталя подтвердила, что это их специалисты добавили валидацию и дали список обязательных полей. Затем уже и мы изменили бизнес-валидацию в нашей системе, чтобы собирать все новые нужные поля. При этом такая валидация ранее отсутствовала.
Вывод: за 10 лет многое меняется. Большие коммуникационные цепочки – очень высокий риск. IT-служба должна была сообщить госпиталю об изменениях, а госпиталь – оповестить всех своих партнеров, а они – поставить в известность свою команду. В этой ситуации может помочь валидация на основе гистограмм. Поскольку даже то, что работало 7 лет, может перестать работать из-за изменений не с вашей стороны. И надо сразу вшивать контрольные точки и контроль распределения результатов интеграции с внешними системами
Татуировка 12: в идеале система должна быть спроектирована так, чтобы её можно было обновлять без downtime в любое время. Число компонентов, которые нельзя обновить без downtime, должно быть минимально
Эта татуировка пришла к нам во время исследования проблем с одной из интеграционных систем.
В больших системах, которые работают с произвольными входными данными (в нашем случае - аудиофайл и документы с результатами визита к врачу), вы по определению не сможете предусмотреть все. А даже если и предусмотрите каким-либо образом, то через 2-3 года появится новый аудиоформат и вам придется дорабатывать систему. Теоретически будущее всегда приносит бесконечное количество возможных входных данных.
Интеграция с системой по доставке писем по почтовым адресам работала хорошо и довольно долго, но в один прекрасный день начались проблемы. Забегая чуть вперед могу сказать, что они начались из-за появления docx формата, который начали использовать пользователи в прилагаемых файлах. И система “не признавала” этот формат как документ Word.
Сейчас мы понимаем, что было, но тогда было ясно, что дело темное. Мы имели какой-то баг, статистически сложно воспроизводимый. В среднем только один запрос из 236 начал “падать”. Это было только в начале появления docx формата, когда абсолютное большинство пользователей использовало старую версию Word. И мы решили усиливать логирование там, где его раньше не было. Однако сделать это было проблематично, потому что надо было останавливать систему.
Частично из-за этого мы стали использовать “модульный монолит”, распилив изначальный сервис в начале на две части, потом на четыре, и добавили систему очередей. После этого стало возможным останавливать и обновлять почти любой компонент системы в рабочее время. Исследования новых типов запросов саппорта стало намного проще проводить.
Архитектура системы - это не только набор областей ответственности, связей между компонентами, но и вопрос обновления систем. С одной стороны сейчас есть микросервисный подход, но, с другой стороны, его проблематично реализовать в условиях ограниченности железа и отсутствия облаков из-за особенностей бизнес-области.
Вывод: при проектировании системы надо стремиться к идеалу, когда любой компонент системы можно было бы остановить на 5 минут и обновить так, чтобы этого не заметили конечные пользователи даже в рабочее время.
Татуировка 13: пользователи могут создать такие данные, которые никто не ожидает. Поэтому надо всегда ориентироваться на здравый смысл
Как мы уже говорили, наша система предназначена для обработки аудиозаписей о диагнозе пациента. Довольно логично ожидать, что доктор вряд ли будет говорить более 5 минут про диагноз одного человека. Логическим исключением является ситуация, когда доктор осматривает несколько человек, такое бывает. Предположим, что такое аудио может быть до часу.
Сейчас эти размышления кажутся элементарными и логичными. А теперь попробуйте понять причину реальных случаев, когда аудиозапись длится 27 часов. Получилось? А теперь представьте случай, когда аудиозапись длится 1,5 месяца. Получилось?
С первой ситуацией мы столкнулись довольно быстро. Логическое объяснение этому существует. Доктор диктует диагноз на диктофон и иногда забывает выключить запись, кладет включенный диктофон в карман и работает дальше. Диктофоны для врачей в Великобритании хорошие, работают до 30 часов без подзарядки.
А вот второй случай мы до сих пор вспоминаем, хотя там не было программной ошибки. В то время от одного из госпиталей поступил заказ на интеграцию с телефонией.Там были установлены телефоны во многих местах и они хотели иметь возможность их использовать для докторов. Они ожидали, что докторы будут подходить к телефону, набирать нужный номер с кодом отделения и говорить диагноз.
В целом все логично и работало в проде в течение 3,5 месяцев. Пока один из докторов не положил трубку телефона неверно, и она так пролежала 1,5 месяца. Потом кто-то заметил, что трубка не так лежит и положил её верно. Когда к нам пришла аудиозапись длиной в 1,5 месяца, было весело.
После этого мы задались вопросом – какая средняя длина аудио в нашей системе? 80% работ – до 6 минут. Еще 19% работ – до часу, менее 1% – до двух часов и 0,012% – более двух часов. В результате стало понятно, что довольно часто врачи забывают остановить запись и делают это позже или аккумулятор на диктофоне просто не может работать больше.
Проблема была в следующем: чтобы обработать более двух часов аудио на клиентском компьютере нужна еще и дополнительная оперативная память. А в госпиталях часто стоят довольно старые компьютеры, из-за этого почти каждый такой аудиофайл приводил к запросам в саппорт.
Когда мы набрали статистику таких “больших” аудиофайлов, наши британские партнеры их проанализировали и пришли к заключению, что дело в невыключенных диктофонах. Когда первые несколько минут - реальный диагноз пациента, а потом - окружающий шум. Поэтому было принято решение поставить ограничение на длину и размер входящего аудиофайла при загрузке записи с диктофона. И теперь, когда пользователь пытался загрузить такие большие аудио файлы, ему выдавалась просьба уменьшить файл перед загрузкой.
Это простое изменение существенно снизило количество запросов в саппорт (примерно на 6%).
Вывод: пользователи могут создать такую ситуацию, которую вы не сможете предугадать. Поэтому на любые входные данные надо ставить ограничение на основании здравого смысла. А в нашем случае их не было, когда система досталась нам по наследству от другой команды разработки.
Татуировка 14: в системах, которые взаимодействуют с пользователями, 100% SLA – это зло
Когда любому клиенту поставляется программное обеспечение, согласуется Service Level Agreement (SLA). До того как произошла смена руководителей саппорта и на нашей стороне, и на стороне британских партнеров, у них был 100% SLA. Т.е. все аудио записи в течении 48 часов в рабочие дни должны были быть обработаны и переданы секретарю для дальнейшей обработки.
На бумаге все это кажется логичным, но есть маленькая проблема – пользователи, которые могут сделать что угодно. Например, создать аудиофайл в 27 часов, когда забывают выключить диктофон. И формально команда, которая отвечает за ручную проверку качества перевода аудио в текст, обязана прослушать 27 часов аудио, потому что там в конце файла гипотетически может быть информация о приеме пациента. Сложно себе представить человека, который сможет прослушать 27 часов аудио.
Другой пример – некоторые диктофоны, так называемые DVR-устройства, имеют функцию шифрования записи. Для ее проигрывания надо знать пароль. Мы сталкивались со случаями, когда покупались новые DVR, на них ставился пароль для шифрования, но нам его забывали передать, передавали только аудиофайлы. И нам приходилось связываться с госпиталем, просить выдать пароль для конкретного устройства, чтобы иметь возможность прослушать аудио. На это уходило время и в результате обработка таких аудио не укладывалась в 48 часов.
Бизнес-проблема заключалась в том, что из-за нарушений SLA, причинами которых были не программные проблемы, госпитали требовали скидку, а скидка - это потерянные деньги. И мы начали думать, как можно решить эту проблему.
Первое, что надо понимать – бизнес-представители в целом разумные люди, но часто они не знают каких-либо исключительных случаев. Поэтому мы начали собирать примеры этих исключений и статистику частотности таких случаев. И произошло маленькое чудо – на основании предоставленных примеров и данных мы смогли договориться об изменении SLA, который просуществовал 6 лет.
Теперь не 100% работ должно быть обработано за 48 часов, а 99.98%. И после этого госпитали прекратили требовать скидку, а бизнес перестал терять деньги из-за нарушений SLA, которые были вызваны “неожиданными” действиями пользователей.
Вывод: когда создается система надо понимать, что SLA в 100% случаев невозможно гарантировать, поэтому лучше брать 99.95%. Не реалистичный SLA на более поздних этапах приведет к проблемам. При этом надо уметь признавать, что есть факты, которые изначально не были учтены, и начинать процесс переговоров.
Выводы
Мы постарались рассказать на примере саппорта о том, как разработчик может развиваться в смежных направлениях. Профессиональный программист – не просто кодер, он может и, как правило, хочет участвовать в развитии продукта, предлагать изменения, чтобы впоследствии видеть результаты своего труда и чувствовать причастность к общему успеху. По нашему мнению, переключение между смежными областями может закрыть потребность разработчика в самореализации. Также оно помогает в расширении кругозора и профессиональном и личностном развитии. Опыт Алексея – достаточно интересный пример того, что иногда многолетнее погружение в один проект дает специалисту не меньше возможностей, чем регулярная смена проектов.
Саппорт третьей линии – одно из полноценных “полей” для роста, которое может быть полезно, в частности, программистам middle и middle+, особенно на длительных проектах. Понимая, как с продуктом взаимодействуют конечные пользователи, специалисты получают более полное представление о системе. Наша практика показывает, что улучшать продукт можно не только разрабатывая фичи, но и предотвращая баги путем настройки и оптимизации бизнес-процессов.
Спасибо! Надеемся, наша серия статей была вам полезна.
Часть 1
Часть 2
