Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

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

2 <h2>Что такое сопровождение</h2>

3 Фаза сопровожденияилиподдержки(Post-Go-Live support) - это этап, на котором программное обеспечение впервые сталкивается с реальными пользователями.

4 Можно сказать, что это продолжение тестирования, потому что протестировать всё заранее невозможно. Само количество тестов бесконечно, так как нельзя предугадать все действия пользователей. Более того, на ПО влияют и остальные факторы: нагрузка, последовательности и одновременность действий, инфраструктура и так далее.

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

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

7 <h2>Что может входить в сопровождение</h2>

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

9 Ответы на вопросы. Компания-разработчик объясняет заказчику, как работает продукт, где находится какая-то кнопка, и так далее.

10 В коммерческом ПО заказчики чаще всего задают вопросы о реконфигурации программы. Другими словами, они уточняют, может ли программа подстроиться под меняющиеся потребности. Причем реконфигурация - это изменение параметров, а не изменение кода. Такие вариации действия системы разработчик заранее вкладывает в ПО.

11 С реконфигурацией есть одна распространенная сложность - чем больше параметров, тем сложнее тестирование. Если параметров очень много, то сложно убедиться, что продукт работает корректно.

12 Рассмотрим такой пример. Представим, что у нас есть 10 параметров:

13 <ul><li>3 поля с числами от 0 до 2 000 000</li>

14 <li>3 поля со строковыми данными, длиной не более 255 и только маленькими латинскими буквами</li>

15 <li>2 выпадающих списка с 5 значениями внутри каждый</li>

16 <li>2 поля с галочками (чек-боксы)</li>

17 </ul>Выглядит не так сложно, но на практике мы столкнемся с огромным количеством вариаций:

18 <ul><li>3 поля по 2 000 000 вариантов</li>

19 <li>3 поля с 6630 вариантами (255 умножаем на 26)</li>

20 <li>2 поля с 5 вариантами</li>

21 <li>2 поля с 2 вариантами</li>

22 </ul>Чтобы получить количество вариантов, надо всё это перемножить. Получится септиллион разных комбинаций настроек - это 10 в 24 степени.

23 Помощь с багами и инцидентами.Чаще всего компания-разработчик помогает заказчику бороться с ошибками в готовой программе.

24 Причем в сопровождение входит борьба и с инцидентами, и с дефектами. Разберемся подробнее, чем отличаются эти понятия:

25 <ul><li>Дефект - это недостаток в продукте, который проявляется в несоответствии требованиям или в неполноте этих требований. Он возникает, если требования поменялись или изначально были сформулированы не совсем точно</li>

26 <li>Инцидент - это внештатная ситуация на продакшене. Он может произойти из-за сбоя, отключения технических средств инфраструктуры, ошибки в действиях пользователя или из-за дефекта, бага или сбоя в самом в программном обеспечении</li>

27 </ul><h2>Как происходит реагирование на инциденты</h2>

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

29 Но на инцидент нужно как-то отреагировать. Мы открываем Jira или другую трекинговую систему и заносим в нее инцидент "Продакшен упал".

30 Далее начинаем выяснять, что случилось и почему:

31 <ul><li>Представим, что сервер отключился, потому что мышь перегрызла провод в серверной. Тогда инцидент не связан с дефектом в системе</li>

32 <li>Представим, что программное обеспечение зависло из-за выполнения какой-то операции. Тогда инцидент вызван багом в программном обеспечении, то есть в ПО проявился неизвестный нам дефект</li>

33 </ul>Как раз во втором случае подключаются тестировщики. Происходит срочный мозговой штурм, чтобы ответить на ключевые вопросы:

34 <ul><li>Что делать, чтобы исправить последствия инцидента? Это приоритетный вопрос, потому что нужно как можно быстрее восстановить работу системы</li>

35 <li>Почему инцидент произошел? В чем основная причина?</li>

36 </ul>Поисками причины занимаются разработчики и тестировщики вместе. Разработчики анализируют код, а тестировщики пробуют пошагово воспроизвести баг из продакшена в тестовой системе. Это облегчает задачу для разработчиков и позволяет сузить поиски.

37 Когда дефект в коде найден, команда рассчитывает сложность его исправления и тестирования. Затем она обсуждает с заказчиком, насколько приоритетно ему получить исправление конкретного бага.

38 Поддержка в случае инцидента - это очень сложно. Код программы может быть очень объемным, поэтому невозможно сразу же понять, что пошло не так.

39 Чтобы упростить задачу, разработчики оставляют себе подсказки в логах системы:

40 <ul><li>Выводят в лог ошибки и исключения интерпретатора</li>

41 <li>Записывают внутренние проверки правильности значений - "Ожидали значение Х, а получилось Y, могла произойти ошибка"</li>

42 </ul>Такие строки в логах могут помочь разработчикам локализовать проблему в коде.

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

44 <ul><li>Статистика активностей</li>

45 <li>Журнал действий</li>

46 <li>Оповещения по уровням серьезности (alert severity levels)</li>

47 <li>Логи с выполняемыми действиями пользователей</li>

48 </ul>Такие системы мониторинга помогают команде проекта либо предотвратить инцидент, либо быстрее разобраться в его причинах.