Программная инженерия

Управление происшествиями

Как преодолеть препятствия и улучшить свое программное обеспечение

Тысячи раз все мы сталкиваемся с программным обеспечением, которое просто не работает.

Он не ломается, не выбрасывает флаг, уведомляющий вас об ошибке — но почему-то просто не делает того, для чего явно предназначен. Это подразумевает несправедливость, плохой дизайн и нулевое ожидание его поведения и кричит: «Я плохо делаю то, что должен делать».

Перспектива инцидента

Ниже описано, что видят ваши клиенты и что видите вы.

Надежность заложена в продукте, а также в процессах, стоящих за ним.

Перспектива решает все. Во-первых, посмотрите на свое программное обеспечение с точки зрения пользователя. Используйте, пробуйте — займите место потребителя.

Улучшите свой продукт в техническом смысле, но затем поработайте над своими процессами и посмотрите, что там тоже можно улучшить.

Всегда анализируйте свое программное обеспечение, функции, угрозы, ошибки, инциденты и проблемы.

Технически все следующие методы и концепции должны быть включены, чтобы мы могли улучшить наше программное обеспечение:

  • Ведение журнала
  • Аудит
  • Метрики инфраструктуры
  • Показатели аппаратных ресурсов
  • Пользовательские метрики
  • Оповещение в реальном времени
  • Аналитика
  • Посмертный анализ
  • Отчет об инцидентах
  • Управление происшествиями

Надежное программное обеспечение не создается и не проверяется за один день. Надежность должна быть достигнута, и то, как вы проектируете, строите и улучшаете свои системы, является частью этого.

Виды отказов и анализ последствий

Существует множество фреймворков и моделей, которые помогают преодолевать проблемы, анализировать и улучшать решения.

Одним из них является анализ видов и последствий отказов. FMEA представляет собой систематическую и упреждающую основу для выявления возможных сбоев и их последствий.

Это процесс проверки компонентов и частей, составляющих вашу систему, который позволяет определить причины и последствия сбоев.

FMEA является основной задачей проектирования надежности.

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

Он просто позволяет вам распознать:

  • Что может пойти не так
  • Почему может произойти сбой
  • Каковы влияние и последствия сбоя

Метрики инцидентов

Сбои, сбои и ошибки — все это приводит к простоям и влияет на надежность системы.

Отслеживание метрик, связанных с инцидентами, является обязательным. Управление инцидентами, их обнаружение, диагностика, разрешение и предотвращение — все это ключевые показатели эффективности вашего инженерного отдела.

Что касается KPI, то вот лишь некоторые из них:

  • Количество оповещений, созданных за определенный период времени
  • Количество инцидентов, произошедших за определенный период времени
  • Среднее время наработки на отказ
  • Среднее время подтверждения
  • Среднее время обнаружения
  • Среднее время решения

Только после того, как вы это сделаете, вы действительно сможете понять, какие сегменты можно улучшить, будь то команда, продукт, услуга или весь уровень вашего инженерного отдела.

Ротация по вызову

Независимо от того, есть ли у вас специальная группа поддержки или ваши разработчики поддерживают внутренние компоненты, вам нужна ротация по вызову.

Доказано, что это повышает качество и надежность вашего программного обеспечения.

Наличие метрики времени, затраченного на обработку инцидентов во время дежурства, также является очень полезным способом получить больше информации.

Тем не менее, все ключевые показатели эффективности, измерения и метрики в мире не могут заменить контекст. Инциденты уникальны, и статистика иногда оказывается ловушкой. Контекстно-зависимый анализ инцидента является обязательным и часто требует лишь щепотки здравого смысла.

Оповещение

Иметь метрики для анализа ваших компонентов — это здорово, иметь оповещения в реальном времени еще до того, как клиент заметит проблему, — это потрясающе.

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

Оповещение и реагирование на проблемы необходимы для обеспечения надежности для потребителей. Ключевым моментом является смягчение последствий — обнаружение проблемы до того, как она разразится, и ваши клиенты даже заметят ее, позволит вам нарисовать совершенно другую картину и позволит вам предотвратить инциденты.

Оповещение обязательно. Исходя из опыта, вы удивитесь, сколько преимуществ дает оповещение. Попробуйте и посмотрите, какие каналы лучше всего подходят для вас:

  • Страницы статуса в реальном времени
  • Электронная почта
  • SMS
  • Slack, Teams или что вы используете

Многие успешные компании имеют все это на месте. Оповещение достойно того, чтобы стать инициативой всей компании вместе с мониторингом.

Методика "шести сигм

Design for Six Sigma, или DFSS — это системный подход и модель в программной инженерии, целью которой является достижение Надежности. Это процесс создания высокого и улучшенного качества.

«Шесть сигм» позволит вам:

  • Статистический контроль качества
  • Методический подход
  • Подход, основанный на фактах и ​​данных
  • Ориентация на проект и цель
  • Ориентация на клиента

Все это является необходимым условием для надежного программного обеспечения. Это позволяет вам, в свою очередь, включить цикл DMAIC, сокращение от Design-Measure-Analyse-Improve-Control.

Существует множество концепций, факторов и аспектов управления инцидентами в программной инженерии, но, надеюсь, вышеизложенное суммирует большую их часть.

Надеюсь, вам понравилась эта история, и вы нашли ее интересной, независимо от того, являетесь ли вы инженером, архитектором, менеджером или дизайнером.

Спасибо за чтение! 🎉