Привет! В последняя статья мы рассказали о 7 из 14 случаев, с которыми мы столкнулись только за последний год, работая в поддержке зарубежного проекта.
Напомним, уже 9 лет мы сотрудничаем с клиентом из Великобритании, который предоставляет программное обеспечение для больниц и обеспечивает ряд этапов бизнес-процессов.
Предыстория проекта а также о том, как работа в поддержке помогает разрабатывать ИТ-продукт и совершенствовать навыки, описано здесь.
Сегодня мы продолжаем рассказ о «татуировках» и выводах, основанных на практическом опыте поддержки.
В предыдущей статье говорилось о безопасности, резервном копировании, взаимодействии с внешними системами, документации и бизнес-процессах.
В этой статье мы рассмотрим виртуализацию, политику хранения данных, ведение журналов, работу с большими данными и многое другое.
Надеемся, эти кейсы помогут вам более комплексно взглянуть на разработку и задуматься о том, как создаваемый продукт будет использоваться пользователями.
В свою очередь, это помогает лучше понять бизнес-процессы клиентов, тем самым еще больше повышая потенциал разработчика и предоставляя ему больше возможностей для роста.
Тату 8: Досконально узнать большую систему практически невозможно.
Мы работали с этой системой более 9 лет и думали, что знаем, как ею пользоваться.
Ведь этапы бизнес-процесса очень просты:
- врач диктует информацию о пациенте,
- аудиофайл переводится в текст и создается документ, содержащий информацию о диагнозе пациента,
- врач одобряет этот файл,
- После одобрения информация поступает в необходимые интеграционные системы, врачу и пациенту.
Если бизнес-процесс был настроен неправильно, этот алгоритм мог не выполняться, и мы посчитали это ошибкой.
После того, как мы ввели эту проверку, в одной из больниц вдруг обнаружили ошибку: было много писем без подписи врача.
Мы были рады, потому что это казалось очевидной ошибкой.
Гордясь собой, мы пошли в больницу и попросили исправить, сказали, кто сделал неправильный бизнес-процесс: в админке у нас логирование, кто, когда и что выполнял.
Ответ больницы нас озадачил: «Все настроено правильно, подписи врача там быть не должно».
Получив ответ, мы решили уточнить, почему такое может быть.
Подробный ответ из больницы нас очень удивил.
Что было «центром» этого дела?
- Наша система интегрирована с 14 различными внешними системами, распространенными в Великобритании.
Одна из них — система с информацией о больных сахарным диабетом.
Мы до сих пор помним, как писали ту интеграцию, она не менялась уже 10 лет, API было очень неудобное.
При тестировании этой системы также было довольно много работы, потому что тестовый сервер было сложно достать.
- В больнице в отделении была еще одна система, параллельная нашей.
Это норма в Великобритании, где разные отделения одной больницы могут использовать разные системы интеграции.
А у разработчиков той «параллельной» системы не было интеграции с системой для больных сахарным диабетом.
И когда их попросили улучшить систему, эта интеграция была оценена как довольно дорогая, так как система была очень «тяжелой».
- Что сделала больница? Работы из этой параллельной системы, одобренные там, были экспортированы в нашу систему.
Также настроили бизнес-процесс экспорта в систему работ о пациентах с диабетом.
И экспортировали информацию о пациентах через нашу систему.
Но при этом от доработки параллельной системы отказались.
Заключение: Если ваша система большая, вы можете надеяться, что знаете основной бизнес-процесс.Но пользователи системы могут начать использовать вашу систему способами, о которых вы удивитесь.
И все же все еще может работать так, как должно.
Тату №9: журнал, не верь пользователям
В один прекрасный день в нашу поддержку пришел запрос — текст с диагнозом пациента после объединения с шаблоном документа начал «двоиться».Эта просьба была необычной.
В шаблоне все было хорошо; других подобных запросов не поступало.
Причины были неясны.
К счастью, в админку мы в свое время добавили логирование, которое не только фиксирует действия пользователя, но и сохраняет все старые версии шаблонов на уровне базы данных.
Оказалось, что секретарь изменила шаблон документа, потому что обновился контактный номер.
Хотя правильнее было бы сказать, что он хотел сменить шаблон, но у него это не получилось.
Он просто добавил еще один в шаблон.
Допустим, старый шаблон с тегами для подстановки данных, логотипами и т.п.
имел вид документа А.
Новый шаблон с тегами и всем остальным имел вид документа Б.
Логично ожидать, что после изменения шаблон будет иметь вид форма Б, но из-за некорректных действий пользователя она стала иметь форму БА, т.е.
пользователь вставил новые данные в начало шаблона и не удалил старые.
Через 12 минут он понял, что допустил ошибку и сделал правильный шаблон с формой Б, удалив форму А.
И никому не сказал, что допустил ошибку.
Всего за эти 12 минут несколько раз был использован неправильный шаблон.
Это объяснило, почему не было новых запросов — шаблон уже был исправлен.
Мы предоставили больнице доказательства, показывающие, что произошло и кто совершил ошибку.
Этого объяснения было достаточно для больницы.
Заключение: Любое изменение конфигурации всегда следует протоколировать не только в админ-панели, но и через триггеры на уровне базы данных.Это необходимо для возможности отслеживать изменения в результате прямых запросов к базе данных.
К сожалению, не все это делают.
Тату 10: Спросить никогда не помешает, даже если клиент изначально говорит «нет»
Работа поддержки становится проще, когда есть хотя бы частичный доступ к базе данных.Но в нашем случае возникла большая проблема – персональные данные.
У нас не должно было быть к ним доступа.
Казалось бы, это «блокировщик» — раз есть конфиденциальные данные, то и доступа быть не может. Но в базе данных содержится масса неконфиденциальных данных — врачи, структура больницы, шаблоны документов, история обработки аудиофайлов и многое другое.
Часто конфиденциальные данные хранятся всего в нескольких таблицах.
И мы предложили клиенту реплицировать базу без полей с конфиденциальными данными.
Это решило и еще одну бизнес-задачу – получение статистической отчетности.
Зачастую руководству больницы необходимо знать, сколько пациентов поступило за день, сколько документов было подписано цифровой подписью за день, сколько аудиофайлов было обработано секретарем и т. д. После обсуждения с клиентом и доказательства того, что в реплицируемой базе данных не будет конфиденциальных данных, это было реализовано.
И теперь, помимо упрощения работы службы поддержки, у нас есть решения для статистической отчетности.
И эти отчеты не могут повлиять на основную базу данных с точки зрения нагрузки на SQL-сервер, потому что они находятся на другой физической машине.
Заключение: Часто клиент говорит «нет», потому что не знает о возможном решении.Поэтому, услышав от клиента «нет», уточните причину и можно ли найти вариант, который устроит всех.
Тату 11: легко написать систему, которая будет работать месяц, сложнее написать систему, которая будет работать 10 лет. За это время многое изменится – и не только технологии.
Статистика показывает, что средний срок работы программистов в ИТ-компаниях составляет от одного до трех лет. Если мы говорим о разработке систем за 10 лет, надо быть готовым к тому, что будет несколько «поколений» программистов.
Но надо учитывать и то, что то же самое происходит и в системах, которые разрабатываются или разрабатываются другими компаниями.
И часто новые поколения приносят с собой новую философию и новые позитивные вещи.
Все бы ничего, если бы не один факт – смена поколений приводит к «обрыву» коммуникационных связей.
Однажды мы анализировали интеграцию с одной внешней системой, предназначенной для обработки результатов приема пациентов.
Идея довольно проста — генерирует сообщение HL7 (стандарт Великобритании) и мы отправляем его в систему интеграции.
В ответ мы получаем результат обработки и протоколируем его.
Время обработки сообщения внешней системой было стабильным – от 200 до 400 мс.
Это нормальный показатель для медицинской сферы.
Мы добавили в систему отчетности графики с гистограммой времени обработки запросов внешней системой и получали их каждую неделю.
Все было хорошо, распределение времени обработки было одним из классических.
В один прекрасный день пришел нестандартный график.
Появилось другое распределение — время обработки от 0 до 50 мс.
Мы были удивлены и начали исследовать этот вопрос.
Оказалось, что внешняя система добавила валидацию данных и сделала отчество пациента обязательным полем, никого об этом не уведомив.
Этим и объясняется быстрая реакция системы — данные не прошли валидацию, и поэтому никакой записи на их стороне не произошло.
В ИТ-службе больницы подтвердили, что именно их специалисты добавили валидацию и предоставили список обязательных полей.
Затем мы изменили процедуру проверки бизнеса в нашей системе, чтобы собрать все новые обязательные поля.
Однако ранее такое подтверждение отсутствовало.
Заключение: Многое изменилось за 10 лет. Крупные коммуникационные сети представляют собой очень высокий риск.ИТ-служба должна была проинформировать больницу об изменениях, больница должна была уведомить всех своих партнеров, а они должны были уведомить свою команду.
В этой ситуации может помочь проверка на основе гистограммы.
Потому что даже то, что работало 7 лет, может перестать работать из-за изменений не с вашей стороны.
И нужно сразу вшивать контрольные точки и контролировать распространение результатов интеграции с внешними системами.
Тату 12: В идеале система должна быть спроектирована так, чтобы ее можно было обновить без простоя в любой момент. Количество компонентов, которые невозможно обновить без простоя, должно быть минимальным.
Эта татуировка пришла к нам во время исследования проблем с одной из систем интеграции.
В больших системах, работающих с произвольными входными данными (в нашем случае аудиофайлом и документами с результатами визита к врачу), всего предусмотреть по определению нельзя.
А даже если вы его каким-то образом обеспечите, то через 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 – это зло
При доставке программного обеспечения любому клиенту согласовывается Соглашение об уровне обслуживания (SLA).До того, как произошла смена лидеров поддержки как с нашей стороны, так и со стороны британских партнёров, у них был 100% SLA. Те.
все аудиозаписи должны были быть обработаны и переданы секретарю для дальнейшей обработки в течение 48 часов в рабочие дни.
На бумаге все это кажется логичным, но есть небольшая проблема — пользователи, которые могут все.
Например, создать аудиофайл в 27 часов, когда забудут выключить диктофон.
И формально команда, отвечающая за ручную проверку качества перевода аудио в текст, обязана прослушать 27 часов аудиозаписи, поскольку в конце файла гипотетически может быть информация о приеме пациента.
Трудно представить человека, способного слушать 27 часов аудио.
Другой пример: некоторые диктофоны, так называемые видеорегистраторы, имеют функцию шифрования записи.
Чтобы играть в нее, вам нужно знать пароль.
Мы сталкивались со случаями, когда были куплены новые видеорегистраторы, на них был установлен пароль шифрования, но нам его забыли сообщить, передавались только аудиофайлы.
И нам пришлось обратиться в больницу и попросить пароль для конкретного устройства, чтобы иметь возможность прослушивать аудио.
Это требовало времени и в результате обработка такого аудио не укладывалась в 48 часов.
Проблема бизнеса заключалась в том, что из-за нарушений SLA, не вызванных проблемами с программным обеспечением, больницы требовали скидку, а скидка была потерянными деньгами.
И мы начали думать, как решить эту проблему.
Первое, что нужно понимать, это то, что представители бизнеса в целом люди разумные, но зачастую им не известны какие-то исключительные случаи.
Поэтому мы начали собирать примеры этих исключений и статистику частоты таких случаев.
И произошло маленькое чудо — на основе предоставленных примеров и данных мы смогли договориться об изменении SLA, которое длилось 6 лет. Теперь за 48 часов необходимо выполнить не 100% работы, а 99,98%.
И после этого больницы перестали требовать скидку, а бизнес перестал терять деньги из-за нарушений SLA, вызванных «неожиданными» действиями пользователей.
Заключение: При создании системы нужно понимать, что SLA не может быть гарантирован в 100% случаев, поэтому лучше брать 99,95%.Нереалистичный SLA приведет к проблемам на более поздних этапах.
При этом надо уметь признать, что есть факты, которые изначально не были учтены, и начать переговорный процесс.
выводы
Мы постарались на примере поддержки рассказать, как разработчик может развиваться в смежных областях.Профессиональный программист – это не просто программист; он может и, как правило, хочет участвовать в разработке продукта, предлагать изменения, чтобы впоследствии увидеть результаты своей работы и почувствовать себя причастным к общему успеху.
На наш взгляд, переключение между смежными направлениями может удовлетворить потребность разработчика в самореализации.
Это также помогает расширить ваш кругозор и профессиональное и личностное развитие.
Опыт Алексея — довольно интересный пример того, что порой многолетнее погружение в один проект дает специалисту не меньше возможностей, чем регулярно меняющиеся проекты.
Поддержка третьей линии — одно из полноценных «полей» для роста, которое может быть полезно, в частности, программистам среднего и среднего+ уровня, особенно на долгосрочных проектах.
Понимая, как конечные пользователи взаимодействуют с продуктом, специалисты получают более полное представление о системе.
Наша практика показывает, что улучшить продукт можно не только за счет разработки функций, но и за счет предотвращения ошибок путем настройки и оптимизации бизнес-процессов.
Спасибо! Надеемся, наша серия статей оказалась для вас полезной.
Часть 1 Часть 2 Теги: #Карьера в IT-индустрии #разработка #Управление продуктом #Service Desk #разработка #поддержка #it-системы
-
Часть 1. Mpi – Введение И Первая Программа
19 Oct, 24 -
Шпаргалка По Opc Da 2 В .Net
19 Oct, 24 -
Firefox 3.1 Бета
19 Oct, 24 -
«Подарки» В Соцсетях – Новые Идеи
19 Oct, 24
