Мы часто сетуем на ошибки в ПО, нередко – очень досадные, когда какая-то упущенная мелочь может обернуться значительными потерями. Самый частый наш вывод – разработчик (поставщик, интегратор) не следит за репутацией и не отлаживает ПО должным образом.
Давайте разберемся, насколько это утверждение справедливо, чего можно ожидать от новых разработок или поставок в смысле надежности, и как следует относиться к неудачам, отказам и потерям, связанным с отказами.
Далее речь будет идти только о ПО прикладного уровня, т.е. мы не будем касаться вопросов надежности системного слоя и отказоустойчивости оборудования, хотя сегодня практически все аппаратные системы основаны на программируемых элементах – начиная от микропрограмм процессоров, микроконтроллеров отдельных блоков, заканчивая достаточно крупными программными комплексами, такими, как BIOS.
К сожалению, причины отказов прикладного ПО бывает трудно отделить от ошибок в ОС или гипервизоре, или багов в любых программных образованиях, на которых строится фундамент прикладных систем — включая разнообразные фреймворки, библиотеки и пр.
Итак, приступаем к главному – к надежности собственно прикладного ПО.
Ошибки и отказы встречаются везде. Вот Starship у Маска имел несколько неудачных (или не очень удачных) запусков, ступени своего SpaceX он тоже не сразу научился сажать. С другой стороны, такие сложнейшие системы, как Space Shuttle или Буран в первом же полете практически полностью выполнили свои миссии. Напрашивается вывод: можно добиваться исключительно высокого уровня надежности ПО (а в упомянутых примерах все, конечно, упирается в ПО), а можно где-то допускать «косяки».
Примеров из нашей практики установки и настройки программного обеспечения для контакт-центров – сколько угодно. Вот, по недосмотру неправильно завершили одну ветку IVR, что вызвало некорректную работу колл-центра. Недосмотрели за логикой управления праздниками и выходными днями – колл-центр стал отрабатывать в выходной день по логике рабочего, и пр. Можно как-то настраивать процессы разработки и отладки с целью уменьшения числа ошибок, но полностью устранить человеческий фактор чрезвычайно сложно.
Все ли случаи отказов ПО одинаковы по своей природе, или можно их классифицировать с тем, чтобы эффективно распределять усилия по их предотвращению? Кстати, правильное понимание причин и логики отказов, как и уровня готовности к ним требуется не только от поставщиков / разработчиков, но и от клиентов / заказчиков.
Один из подходов состоит в рассмотрении проблемы с точки зрения тиражности: чем выше тираж системы, тем больше внимания надо уделять отладке. Будучи в целом с ним согласным, я не стал бы ставить этот подход во главу угла, т.к. параметр тиражности может иметь значение лишь при прочих равных, при этом те самые «прочие» могут влиять на ситуацию на порядок существеннее. Например, космические системы имеют крайне маленькую тиражность, так что же? Можно не отлаживать? Слишком накладно будет…
Вот в этом и лежит корневой вопрос рассматриваемой темы.
Автор, в далекие восьмидесятые годы прошлого века, в качестве программиста (аналитика, архитектора, руководителя проекта – все было в одном флаконе) принимал участие в разработке ПО для одной из критических систем Бурана. Ну, и участвовал в ряде других проектов аналогичного класса. Однако уже больше четверти века занимается коммерческими проектами. Есть что анализировать и сравнивать. Разнообразные подходы и методы, разные результаты.
Начнем с космических систем. Основная отличительная черта – стоимость ошибки стремится к бесконечности. Следовательно, стоимость мероприятий по предотвращению ошибки тоже фактически ничем не ограничена. Там не об экономической стороне проекта шла речь, а о том, чтобы так построить многоуровневую и многослойную систему отладки, чтобы любую потенциальную ошибку и неточность можно было бы правильно диагностировать и устранить. Т.е. все слои архитектуры должны быть под контролем.
Легко сказать: а операционные системы, библиотеки? (Слова «фреймворк» тогда не употребляли, по крайней мере, в России). Решение простое: все это разрабатывалось с нуля строго под задачу. А что делать с динамическим поведением систем, когда в силу внешних воздействий, носящих статистический характер, невозможно добиться воспроизводимости поведения, что является необходимым условием для эффективной отладки?
Для этого существовали свои методы, позволявшие сочетать отладку в условиях воспроизводимого поведения системы при моделировании детерминированных внешних воздействий и регистрацию их влияния в реальных условиях.
Все логично, но думаю, знающие люди могут себе представить, что системы диагностики и отладки такого уровня многократно превосходили стоимость собственно разработки отлаживаемого ПО (причем была задействована не только программная, но и аппаратная отладочная оснастка). Многократно превосходили – значит, на порядок и более.
Краткий вывод: в «обычной» жизни такие подходы неприменимы, так никакой продукт до релиза довести не удастся.
Давайте еще раз обратим внимание на Маска. У него системы космического назначения тоже иногда отказывают (падают, взрываются). Что, не научился строить системы отладки и диагностики? Вряд ли. Выскажу предположение: он балансирует стоимость потерь при неудачах и стоимость отладки. Другими словами: у него стоимость отладки примерно сравнялась со стоимостью потенциальных потерь при отказе, и дальше наращивать стоимость систем и процедур предварительной отладки смысла нет: дешевле протестировать систему в реальных испытаниях (это иллюстрация смысла слова «многократно», упомянутого выше). Кстати, стоимость собственно времени, затрачиваемого на отладку, тоже стоит учитывать: стоимость невыполнения контракта в срок, стоимость потерь от опережения конкурентами, и пр.).
Это все, конечно, статистические спекуляции, здесь баланс, скорее, основан на интуиции, но все же, это не устраняет его природу.
Вернемся на землю, к нашему ПО для колл-центров.
У него надо различать три типа компонентов, имеющих разное влияние на надежность системы в целом.
Первый и самый критичный тип компонентов по влиянию на надежность - это ядро. То, что обслуживает управление звонками, соединение с телефонным провайдером, обмен с рабочими местами агентов (звук, данные, иногда – видео).
Здесь налицо высокая тиражность (ядро используется в неизменном виде во всех инсталляциях) и прямое влияние на безотказность всей системы, использующей это ПО, т.е. самого колл-центра как функции.
Требования – самые, что ни на есть, высокие – примерно, как к космическим системам (почти не шучу). Стоимость отказа может быть высокой не только потому, что простой каждой реальной инсталляции обходится дорого, но и потому, что тиражность увеличивает эту стоимость пропорционально числу используемых экземпляров. Еще один мультипликатор стоимости отказа связан с тем, что в отношении ядра трудно построить какие-то обходные решения, а найти и устранить неисправность могут только авторы системы.
Второй тип компонентов – разнообразные сервисные функции, включающие интерфейс агента, стандартные блоки IVR, всевозможные интеграционные API и пр. Таких функций очень много, и далеко не все они используются в каждом конкретном проекте, так что тиражность каждой функции в целом много ниже, чем у ядра, и обычно есть возможность в каждом частном случае компенсировать отказы таких компонентов за счет реализации временных функциональных схем и прочих «костылей», позволяющих без особых потерь дождаться момента, когда разработчик устранит недостаток.
Требования к надежности функций этого типа в целом ниже, как и возможности отладки (спектр таких компонентов чрезвычайно широк, высокий темп развития не позволяет вести достаточно глубокую отладку).
Средства защиты от ошибок в упомянутых компонентах:
- прежде всего, это тестирование системы, настроенной на выполнение требований заказчика, в условиях, максимально приближенных к реальным (на этапе внедрения, т.е. при подготовке к эксплуатации). Это означает, что, даже если существует много маршрутов обработки вызовов, надо проверить все. Много сочетаний параметров, с которыми работает агент – по меньшей мере, выбрать для проверки наиболее вероятные, осознавая, что любое непроверенное сочетание означает потенциальный отказ. И так далее, исходя из этой позиции.
- организация периода опытной эксплуатации, направленная на выявление ошибок. Именно на этот период придутся наиболее вероятные отказы. Поэтому опытная эксплуатация должна охватывать все возможные режимы (все входящие и исходящие проекты, виды интеграции и пр.), поскольку надо понимать, что это, по сути, комплексная отладка ПО в реальных условиях. Игнорирование такого подхода увеличивает риски финансовых и репутационных потерь в дальнейшем.
- При опытной эксплуатации команда внедрения (professional service вендора или системный интегратор) должна быть в состоянии высокой готовности, и вместе с заказчиком принимать решения об экстренных мерах при обнаружении ошибок или неточностей в работе.
- готовность со стороны вендора к внесению оперативных исправлений. Осознавая, что вероятность ошибок в компонентах второго типа существенно отличается от нуля, он должен построить процедуру устранения отказов за конечные, весьма ограниченные промежутки времени.
Третий тип компонентов связан с самыми высоким рисками (error prone). Это настройки системы на требования заказчика (IVR, экраны агентов, маршруты вызовов, отчеты, кастомные скрипты и пр.). Невнимательность команды внедрения и недостаточный уровень отладки, конечно, не могут быть оправданы, однако влияние пресловутого «человеческого фактора» при этом значительно выше, поскольку возможности отладки на этапе настройки системы зачастую весьма ограничены.
Вспомните о стоимости отладочных средств, применяемых в космической отрасли. Ситуация в колл-центровых проектах в этой части является несравнимой, прежде всего потому, что в этом случае применение специальных средств отладки (таких, как имитация всех видов вызовов, автоматическая проверка разных режимов работы, имитация отработки всех видов реальных ситуаций) обычно бюджетом вообще не предусматриваются. То есть отладка сводится к тестированию на единичных примерах, с ручными заданиями параметров, ручными вызовами (например, не охватывающими весь номерной план), не проверяющих сочетание всех условий IVR, всех параметров интеграции и других условий. Возможно применение контроля кода и настроек «в четыре глаза», но это влечет за собой значительное увеличение бюджета, и не всегда эффективно.
Как быть с этим типов компонентов, как защищаться?
В целом подходы те же, что для второго типа. Хорошая новость – то, что авторами всех решений, охватывающих компоненты третьего типа, являются сами внедренцы, значит, за устранением проблем далеко ходить не надо, обращения к вендору не понадобятся. Плохая новость состоит в том, что вероятность ошибок с компонентами третьего типа обычно выше, чем с компонентами второго типа.
Какие же выводы можно сделать из всего этого?
- Стоимость потерь от ошибок при работе системы уравновешивается затратами на тестирование и отладку. Это универсальное правило, работающее и для космических систем, и для колл-центров, и вообще для всех типов программных решений.
- Внимательное отношение Заказчика к программе приемо-сдаточных испытаний, готовность выделить время и средства на дополнительное тестирование существенным образом влияет на повышение надежности системы.
- Готовность к устранению ошибок и проблем с настройками, правильное планирование комплексной отладки (она же – опытная эксплуатация) – залог минимизации ущерба, наносимого ошибками.
- Если стоимость ошибок велика (как в случае систем, обслуживающих экстренные службы), в проект должно быть включено использование специальной оснастки (как программной, так и аппаратной) для разнообразных видов тестирования и автоматизации испытаний, применяемой при отладке систем, к которым предъявляются повышенные требования.
Оглядываясь назад
Остались за кадром средства парирования аппаратных отказов, отказов уровня платформы (ОС, гипервизоры, средства управления контейнерами и пр.), динамического парирования программных отказов. Здесь мы не касались использования мониторинга – автоматического и ручного для извещения о предкритических и критических ситуациях. Вопросы резервного копирования – отдельная область, играющая огромную роль в обеспечении непрерывности работы. Все это пересекается с рассматриваемой областью лишь частично, но так же критически важно с точки зрения снижения стоимости отказов и сокращения времени их устранения.