Ранее в курсе мы обсуждали, как команды разрабатывают продукты от идеи до релиза. Но есть ли жизнь после выхода в продакшен? Об этом мы поговорим в этом уроке. Мы изучим фазу сопровождения продукта, которая начинается сразу после релиза.
Что такое сопровождение
Фаза сопровождения или поддержки (Post-Go-Live support) — это этап, на котором программное обеспечение впервые сталкивается с реальными пользователями.
Можно сказать, что это продолжение тестирования, потому что протестировать всё заранее невозможно. Само количество тестов бесконечно, так как нельзя предугадать все действия пользователей. Более того, на ПО влияют и остальные факторы: нагрузка, последовательности и одновременность действий, инфраструктура и так далее.
Поэтому есть ненулевая вероятность, что ошибка просочится в продакшен и когда-нибудь даст о себе знать. Тогда произойдет инцидент — именно так называют случаи, когда дефект показался в Продакшене. Инциденты портят имидж заказчику и разработчику, приносят убытки и головную боль всем, кто поддерживает работу системы.
Чтобы снизить вероятность инцидента, команды тщательнее готовятся и проверяют все на всех этапах жизненного цикла ПО. Чтобы сопровождение было еще надежнее, эту фазу планируют еще в самом начале разработки ПО.
Что может входить в сопровождение
Фаза сопровождения зависит от продукта, компании и её отношений с клиентом. Также фаза сопровождения может быть как бесплатной для заказчика, так и платной. Далее мы обсудим два аспекта сопровождения, которые встречаются чаще всего.
Ответы на вопросы. Компания-разработчик объясняет заказчику, как работает продукт, где находится какая-то кнопка, и так далее.
В коммерческом ПО заказчики чаще всего задают вопросы о реконфигурации программы. Другими словами, они уточняют, может ли программа подстроиться под меняющиеся потребности. Причем реконфигурация — это изменение параметров, а не изменение кода. Такие вариации действия системы разработчик заранее вкладывает в ПО.
С реконфигурацией есть одна распространенная сложность — чем больше параметров, тем сложнее тестирование. Если параметров очень много, то сложно убедиться, что продукт работает корректно.
Рассмотрим такой пример. Представим, что у нас есть 10 параметров:
- 3 поля с числами от 0 до 2 000 000
- 3 поля со строковыми данными, длиной не более 255 и только маленькими латинскими буквами
- 2 выпадающих списка с 5 значениями внутри каждый
- 2 поля с галочками (чек-боксы)
Выглядит не так сложно, но на практике мы столкнемся с огромным количеством вариаций:
- 3 поля по 2 000 000 вариантов
- 3 поля с 6630 вариантами (255 умножаем на 26)
- 2 поля с 5 вариантами
- 2 поля с 2 вариантами
Чтобы получить количество вариантов, надо всё это перемножить. Получится септиллион разных комбинаций настроек — это 10 в 24 степени.
Помощь с багами и инцидентами. Чаще всего компания-разработчик помогает заказчику бороться с ошибками в готовой программе.
Причем в сопровождение входит борьба и с инцидентами, и с дефектами. Разберемся подробнее, чем отличаются эти понятия:
- Дефект — это недостаток в продукте, который проявляется в несоответствии требованиям или в неполноте этих требований. Он возникает, если требования поменялись или изначально были сформулированы не совсем точно
- Инцидент — это внештатная ситуация на продакшене. Он может произойти из-за сбоя, отключения технических средств инфраструктуры, ошибки в действиях пользователя или из-за дефекта, бага или сбоя в самом в программном обеспечении
Как происходит реагирование на инциденты
Представим, что мы разработали программу. Уже на этапе сопровождения продакшен упал. Клиенты не могут подключиться и обрывают горячую линию, мы сами не можем зайти на сервер и найти проблему.
Но на инцидент нужно как-то отреагировать. Мы открываем Jira или другую трекинговую систему и заносим в нее инцидент «Продакшен упал».
Далее начинаем выяснять, что случилось и почему:
- Представим, что сервер отключился, потому что мышь перегрызла провод в серверной. Тогда инцидент не связан с дефектом в системе
- Представим, что программное обеспечение зависло из-за выполнения какой-то операции. Тогда инцидент вызван багом в программном обеспечении, то есть в ПО проявился неизвестный нам дефект
Как раз во втором случае подключаются тестировщики. Происходит срочный мозговой штурм, чтобы ответить на ключевые вопросы:
- Что делать, чтобы исправить последствия инцидента? Это приоритетный вопрос, потому что нужно как можно быстрее восстановить работу системы
- Почему инцидент произошел? В чем основная причина?
Поисками причины занимаются разработчики и тестировщики вместе. Разработчики анализируют код, а тестировщики пробуют пошагово воспроизвести баг из продакшена в тестовой системе. Это облегчает задачу для разработчиков и позволяет сузить поиски.
Когда дефект в коде найден, команда рассчитывает сложность его исправления и тестирования. Затем она обсуждает с заказчиком, насколько приоритетно ему получить исправление конкретного бага.
Поддержка в случае инцидента — это очень сложно. Код программы может быть очень объемным, поэтому невозможно сразу же понять, что пошло не так.
Чтобы упростить задачу, разработчики оставляют себе подсказки в логах системы:
- Выводят в лог ошибки и исключения интерпретатора
- Записывают внутренние проверки правильности значений — «Ожидали значение Х, а получилось Y, могла произойти ошибка»
Такие строки в логах могут помочь разработчикам локализовать проблему в коде.
Иногда возникает еще одна трудность: сложно заметить, если что-то пошло неправильно. Например, если у магазина есть проблемы с оплатой заказа, клиент позвонит на горячую линию и скажет о проблеме. Не во всех продуктах возможно такое быстрое реагирование, поэтому в программное обеспечение закладываются системы мониторинга:
- Статистика активностей
- Журнал действий
- Оповещения по уровням серьезности (alert severity levels)
- Логи с выполняемыми действиями пользователей
Такие системы мониторинга помогают команде проекта либо предотвратить инцидент, либо быстрее разобраться в его причинах.
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
- Статья «Как учиться и справляться с негативными мыслями»
- Статья «Ловушки обучения»
- Статья «Сложные простые задачи по программированию»
- Вебинар «Как самостоятельно учиться»
Для полного доступа к курсу нужен базовый план
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.
