Соответственно, мы можем принять меры в отношении всех этих угроз.
Видов мер 4:
1. Предотвращение. То есть, мы изначально не вносим в систему дефекты. Это ответственность системных аналитиков и тех, кто внедряет методы разработки. Аналитики тут отвечают за выявление возможных нештатных ситуаций и за контроль полноты рассмотрения всех вариантов — зачастую дефекты возникают ещё на этапе спецификации, когда не описано поведение системы в некоторой возможной ситуации. Тут же можно оценить — какие ситуации возможны и какова их вероятность, а точнее — риски (вероятность x ущерб). На этом этапе аналитик должен выяснить всё, что связано с диапазонами допустимых значений данных и эксплуатационных параметров и подумать над граничными условиями.
Сколько у нас может быть пользователей (документов/запросов/клиентов) максимально? В среднем? А сколько из них одновременно будут работать/создаваться/обрабатываться? А какой прирост в год/месяц/день/секунду? А если у нас не будет ни одного пользователя (с определенной ролью)/документа/организации/значения в справочнике? И т.д.
Иногда дефекты с проверкой значений возникают в неожиданных местах: длина имени файла, допустимые символы в учётной записи пользователя, точность округления значения с плавающей запятой, минимальное значение даты — это из того, что сам видел незамеченного уже на проде.
2. Устранение — на этапе разработки (это разные виды тестирования, ревью кода и т.д.) или на этапе эксплуатации — уже в рамках поддержки. С этой мерой аналитики обычно не сталкиваются — даже если участвуют в приёмке, фокусируются на happy path. Однако кто-то должен об этом задуматься и проверить.
3. Прогнозирование — наблюдение за параметрами системы и контроль тенденций, приводящих к возможным сбоям. Например, если у нас заканчивается место на диске, лучше узнать об этом заранее и предпринять меры. Или если растет время ответов от внешнего сервиса — это ещё не ошибка, но сигнал о возможной ошибке — так работает паттерн circuit breaker, например.
Это всё про мониторинг — как на техническом уровне, так и на бизнесовом. При этом на техническом инженерные команды часто ставят какой-нибудь Zabbix, но не настраивают прогнозирующие функции, только оповещения, когда уже совсем всё сломалось. А бизнесовые параметры вообще не мониторят — например, шлюз торговой площадки физически работает, но вместо типичных 100 сделок в день присылает только 4 — это сегодня так мало сделок, или уже какая-то ошибка?
4. Устойчивость к сбоям — когда система продолжает работать несмотря на сбои. Подумаешь, что-то упало — у нас есть альтернативный способ сохранять работоспособность, или мягко деградировать (graceful degradation). Подумаешь — в систему пытаются ввести мусор, или инъекцию, а мы ввод санитаризируем. Сюда относятся обработчики ошибок и реакция на них, когда мы не можем их предотвратить — скажем, на входе. Что если нам пришлют данные не в том формате? Если не будет хватать какого-то поля? Будут лишние поля? Пришлют слишком много данных, а мы ждали мало?
Или, например, функция рестарта после отказа. В пределе получаем подход Let It Crash, когда мы можем быстро перезапустить упавший процесс, неважно по какой причине он упал — потом разберемся по логам, давайте перезапустимся сначала. Тут возникают различные функциональные требования — или не возникают, если решение отдано архитекторам и команде эксплуатации. Они-то что-то придумают и про мониторинг, и про логи, и про средства восстановления, но вот будет ли это где-то зафиксировано? Будет ли документация на это? И как это будет проверяться?
Видов мер 4:
1. Предотвращение. То есть, мы изначально не вносим в систему дефекты. Это ответственность системных аналитиков и тех, кто внедряет методы разработки. Аналитики тут отвечают за выявление возможных нештатных ситуаций и за контроль полноты рассмотрения всех вариантов — зачастую дефекты возникают ещё на этапе спецификации, когда не описано поведение системы в некоторой возможной ситуации. Тут же можно оценить — какие ситуации возможны и какова их вероятность, а точнее — риски (вероятность x ущерб). На этом этапе аналитик должен выяснить всё, что связано с диапазонами допустимых значений данных и эксплуатационных параметров и подумать над граничными условиями.
Сколько у нас может быть пользователей (документов/запросов/клиентов) максимально? В среднем? А сколько из них одновременно будут работать/создаваться/обрабатываться? А какой прирост в год/месяц/день/секунду? А если у нас не будет ни одного пользователя (с определенной ролью)/документа/организации/значения в справочнике? И т.д.
Иногда дефекты с проверкой значений возникают в неожиданных местах: длина имени файла, допустимые символы в учётной записи пользователя, точность округления значения с плавающей запятой, минимальное значение даты — это из того, что сам видел незамеченного уже на проде.
2. Устранение — на этапе разработки (это разные виды тестирования, ревью кода и т.д.) или на этапе эксплуатации — уже в рамках поддержки. С этой мерой аналитики обычно не сталкиваются — даже если участвуют в приёмке, фокусируются на happy path. Однако кто-то должен об этом задуматься и проверить.
3. Прогнозирование — наблюдение за параметрами системы и контроль тенденций, приводящих к возможным сбоям. Например, если у нас заканчивается место на диске, лучше узнать об этом заранее и предпринять меры. Или если растет время ответов от внешнего сервиса — это ещё не ошибка, но сигнал о возможной ошибке — так работает паттерн circuit breaker, например.
Это всё про мониторинг — как на техническом уровне, так и на бизнесовом. При этом на техническом инженерные команды часто ставят какой-нибудь Zabbix, но не настраивают прогнозирующие функции, только оповещения, когда уже совсем всё сломалось. А бизнесовые параметры вообще не мониторят — например, шлюз торговой площадки физически работает, но вместо типичных 100 сделок в день присылает только 4 — это сегодня так мало сделок, или уже какая-то ошибка?
4. Устойчивость к сбоям — когда система продолжает работать несмотря на сбои. Подумаешь, что-то упало — у нас есть альтернативный способ сохранять работоспособность, или мягко деградировать (graceful degradation). Подумаешь — в систему пытаются ввести мусор, или инъекцию, а мы ввод санитаризируем. Сюда относятся обработчики ошибок и реакция на них, когда мы не можем их предотвратить — скажем, на входе. Что если нам пришлют данные не в том формате? Если не будет хватать какого-то поля? Будут лишние поля? Пришлют слишком много данных, а мы ждали мало?
Или, например, функция рестарта после отказа. В пределе получаем подход Let It Crash, когда мы можем быстро перезапустить упавший процесс, неважно по какой причине он упал — потом разберемся по логам, давайте перезапустимся сначала. Тут возникают различные функциональные требования — или не возникают, если решение отдано архитекторам и команде эксплуатации. Они-то что-то придумают и про мониторинг, и про логи, и про средства восстановления, но вот будет ли это где-то зафиксировано? Будет ли документация на это? И как это будет проверяться?