Ищем точки роста в системе
Пока выбор аналогов промышленных решений оставляет желать лучшего, действующие на предприятиях системы работают и их предпочитают не менять, а улучшать и по возможности предотвращать поломки. Где и как искать источники сбоев в существующих системах, расскажут эксперты ИТ-компании SimbirSoft.
Статья может быть полезна техническим директорам, аналитикам, специалистам службы качества, а также руководителям производственных отделов.
Зачем искать проблемы в системе
Хотите сократить издержки или заработать на ИТ-продукте? Скажем так, всё возможно, поскольку цель любого программного продукта — облегчить и улучшить жизнь пользователей, повысить эффективность процессов и помочь тем, кто его разрабатывает и поддерживает. Другими словами, с помощью ПО можно сократить издержки и увеличить монетизацию проекта.
Чтобы не быть голословными, приведем несколько фактов из нашей практики. На одном из проектов, который достался нам после другой команды, за 6 месяцев работы по оптимизации на саппорте мы смогли на 27% уменьшить затраты клиента на техподдержку. Добиться таких результатов помогла автоматизация проверки настроек системы, ошибки в которых были найдены на основе анализа действий пользователей.
На саппорте другого проекта, который также приняли на доработку, мы иногда отмечали нарушение сроков выполнения работ в бизнес-процессе и нарушения SLA (service level agreement). При этом большая часть проблем была вызвана действиями пользователей, администраторов и внешних T-систем. Результат — компания теряла деньги на скидках, поскольку из-за нарушения SLA приходилось предоставлять скидки клиентам.
Последовательное добавление мониторинга бизнес-процесса позволило визуализировать ситуации и анализировать конкретные случаи нарушения SLA, найти слабые места и исправить их организационным (создавая нужные инструкции) или программным (добавляя новый функционал) способом. После 7 месяцев такой работы нарушения SLA исчезли, соответствующие скидки ушли в прошлое, и прибыль клиента выросла.
Как показывает практика, нельзя мгновенно исправить систему, которая находится в эксплуатации. В таких случаях эффективны статистические методы и методология Канбан, особенно если комбинировать её с другими подходами к контролю качества системы. Даже если использовать самые современные подходы, но не учитывать при этом специфику целевой аудитории и предметную область программы, результаты (улучшение SLA, саппорта и пр.) будут не очень хорошими.
Где зарыта собака: ищем узкие горлышки
При разработке архитектуры ПО необходимо принимать во внимание требования и возможности бизнеса. При проектировании системы, которая будет интегрироваться с какими-либо устройствами, нужно учитывать проблемы оборудования и особенности его подключения.
Возьмем простой пример. Предположим, у вас есть микрофон, с которым надо интегрироваться, чтобы получить с его помощью аудиозапись и использовать в дальнейшей работе. В этом случае могут возникнуть следующие проблемы:
- его можно держать неправильно;
- кнопка может быть неисправна: пользователь говорит, а запись не ведется, поскольку он выключен;
- у микрофона могут быть неверные настройки в системе или проблемы с драйвером;
- подключение через USB может быть нестабильным и от любого движения микрофона USB-кабель будет выпадать;
- тип аудиоформата может быть разным для разных моделей микрофона.
Чтобы пережить отдельные сбои, которым так или иначе подвержено оборудование, при проектировании ИТ-системы следует ввести избыточность: двойные контроли, репликации, дублирования, несколько сетевых кабелей и т.п. Это повышает вероятность того, что в любой момент времени будет присутствовать хотя бы одна неисправность, что усложняет систему.
Следующий источник возможных ошибок системы — пользователи. К сожалению, застраховаться от ошибок пользователей не поможет даже автоматизация. Более того, она даже повышает риск их появления, если автоматизация выполнена при наличии пропущенных бизнес-правил.
Когда человек работает в системе, он может совершить ошибку или сообщить, что не знает, как выполнить то или иное действие, и получит разъяснения, если что-то сделал не так. Но если при проработке бизнес-правил было что-либо пропущено, обнаружить это в автоматизированной системе будет сложнее. Не секрет, чем раньше проблема будет обнаружена, пока она не затронула другие процессы, тем проще ее исправить.
Поэтому рекомендуем к средствам автоматизации добавить механизмы мониторинга и контрольных точек, выбранных на основании существующего бизнес-процесса. Система мониторинга не будет зависеть от основной — её можно обновлять хоть каждый день, добавляя новые правила и улучшая предсказуемость системы в целом.
Мониторинг состояния существующих систем на некоторых предприятиях позволил выявить, что есть два критических источника проблем. Как ни странно, это не код, а пользователи (администраторы и рядовые сотрудники) и оборудование, о чем мы и говорили выше.
Безусловно, мы не исключаем ошибок в самих программах, но они не являются критическими, поскольку система работает и дает результат. Так, за несколько лет активного использования физическое устройство, скорее всего, потребует полной или частичной замены. Вероятность того, что администратор системы за это время сменится, тоже довольно высока. Но бизнес-логика, которая заложена в коде, будет по-прежнему работать: некоторые бизнес-правила в больших, долгоживущих системах исправно работают десятилетиями
Вывод: существующие системы требуют оптимизации бизнес-процессов, детектирования и предотвращения проблем как можно раньше. Причем это нужно выполнять, учитывая особенности деятельности предприятия и технического анализа критических точек.
Что делать, если сбоев в системе все равно не избежать?
Отметим, что эти рекомендации относятся к менеджменту.
1) Осознать и принять факт: независимо ни от чего в системе будут происходить различные сбои, рано или поздно что-то может пойти не так. Так вы будете готовы спроектировать детектирование и возможную реакцию системы на конкретные сбои. По аналогии с тем, как конструкторы автомобилей создают зоны деформации, можно спроектировать защитные режимы сбоев, которые будут изолировать повреждения и защищать остальные компоненты системы.
Если этого не сделать, вы можете иметь дело с непредсказуемыми и даже опасными сбоями в работе системы, последствия которых потом будете устранять не один день. Например, на некоторое время — от 0,5 секунды до нескольких часов — Сеть может выйти из строя, или внезапно закончится лицензия приобретенного ПО, или еще что-то произойдет.
2) Помнить, что программное обеспечение является следствием бизнес-процессов. И если в ИТ-системе происходит что-то неожиданное, есть несколько причин: в системе возникла ошибка, пользователь совершил неверное действие, что-то не так с бизнес-процессом или наблюдаются проблемы с внешними системами.
При разработке ПО для крупного предприятия часто невозможно предусмотреть все комбинации, как будут его использовать сотрудники и какие ошибки могут сделать. Каждое отклонение требует оперативного выявления, исследования и принятия мер.
3) Иметь реалистичные ожидания от ПО, особенно если оно предназначено для интеграции или автоматизации существующих бизнес-процессов. Будущие пользователи системы должны понимать пользу от автоматизации, поэтому её предпочтительнее проводить шаг за шагом, собирая обратную связь не только от них, но и от бизнеса. Изменение одного компонента системы может повлиять на другие, поэтому не рекомендуем автоматизировать сразу все стадии бизнес-процесса. Это поможет решать проблемы по порядку или избежать их на следующих этапах.
Так, например, в системе автоматизации бизнес-процессов одной сети клиник мы интегрировали систему детектирования различных отклонений от ожиданий. Неожиданно для нас быстрая реакция на «появление» отклонений в начале бизнес-процесса и их корректировка позволила предотвратить большие проблемы с одной из внутренних систем организации, задействованной на последнем этапе бизнес-процесса.
В сложных бизнес-процессах, как правило, не существует одной большой проблемы, есть комбинации «малых» и «средних», которые в совокупности приводят к «большим».
4) При доработке ПО закладывать точки контроля для нового или модифицированного функционала. Запустить систему относительно просто, гораздо сложнее обеспечить постоянное качество на протяжении нескольких лет. Некоторые системы клиентов мы поддерживаем уже более 9 лет. И на основе нашей практики можем сказать, что накопление данных, изменение бизнес-процессов и другие изначально непланируемые вещи происходят, и это нормально.
Поэтому важно закладывать точки контроля бизнес-процессов и систему, которая будет их проверять. Это позволит понимать, что все идет в соответствии с ожиданиями, а если где-то пойдет отклонение, исследовать причину и принять меры.
5) Понять, чего не должно происходить в системе, и добавить это в систему контроля. Предположим, вы ожидаете, что из какого-либо подразделения компании будут регулярно поступать новые данные. Когда они внезапно перестанут приходить или их объем составит 0 байт, это будет указывать на то, что что-то произошло и это нужно исследовать, хотя формально «явной» ошибки программа не выдаст. Так вы сможете предотвратить часть проблем.
Проектирование систем, которые интегрируются с внешними устройствами, — это интересная задача для разработчиков. Поскольку там появляются:
- люди, которые могут допускать ошибки;
- устройства, которые могут повлечь за собой череду проблем;
- другие ограничения.
Имея правильные подходы и ожидания для работы с этими проблемами, с ними можно справиться и найти точки для роста, оптимизации, повышения качества и автоматизации.
