Антон вырос от разработчика до менеджера проектов, это был его первый доклад на конференции и удачный. Большинство участников в этот слот пошли слушать доклада Орлова и Панкратова, с которыми я знаком по различным конференциям, и потому решил послушать неизвестного мне докладчика. И не пожалел.
Доклад, по сути, представляет собой некоторый список мест, где в проекте потенциально могут быть грабли и, чтобы проект был успешным, на эти места следует обращать внимание. Неизвестных для себя мест я не обнаружил. Однако, по мере рассказа вспоминал, что о некоторых из них — рассказывал новым разработчикам. А списка в компании — нет. Приведенный в докладе вполне можно взять за основу, потому что все пункты — по делу. Ну и кто-то вполне может обнаружить и новое. неизвестное для себя.
Основные места, в которых возникают грабли.
- Пользователи — они могут портить даные из-за ошибок в системе.
- Интеграция с внешними сервисами
- Работа после наката обновлений
Сбои — потери — разгребание проблем.
Как избежать?
- Типовые проблем — типовые решения. Их надо знать и делать (бэкап, например)
- Новые проблемы — будут всегда, тут типовых решений нет. Но можно подготовиться — средства диагностики и средства восстановления. Восстановление — более-менее универсально и не зависит от конкретной проблемы.
Кто отвечает за это? Разработчик. А то он будет и расхлебывать.
Что такое «заднее чутье»?
- Источники: Люди, ПО, Железо, Процессы
- Возможные проблемы
- Решения для них
- Проверка, что решения работают (например, из бэкапа — можно поднять систему). Это — важно.
Прототип системы: нужен минимум — диагностика. В первой боевой версии — желателен максимум защиты. И далее надо постоянно поддерпживать
Дальше много частных решений.
- Таких как мониторинг или бэкапы.
- Протокол взаимодействия при интеграции; Проверка по контрактам входа-выхода
- Повторение запросов, рассчитывать протоколы на это.
- Резервные каналы синхронизации. Ннапример, с мобильного девайса, когда штатно не получается.
- Вести логи, уметь их передавать.
- Изоляция внешней системы — шлюз.
Работа с пользователем.
- Механизмы восстановления. Напрмиер при ошибочном удалении или редактирвоании
- Предусматривать возможность срезать углы, позволяя нарушать правила. Например, сохранять неконсистентные черновики.
- Сохранять простой вариант UI
- Обработчик ошибок верхнего уровня. Пользовательская диагностика. Интерфейс пользователя дляы ошибок.
- Глюки из-за проигнорированной ошибки: Кидайте исключения, а не код возврата. Проверяйте контракт.
- Уведомлять разработчика автоматически, отслеживать действия пользователя.
- Изолировать объекты разных пользователей (usec-spec)
Релиз
- Автоматический накат по одной кнопке
- Блокировать работу на время релиза.
- Порча базы патчами: бэкапы до и после, сравнение базы до и после, альфа-тест на отдельной площадке.
- Бета-тестирование — использование новой версии частью пользователей в продакшн, пока остальные на старой версии
Поддержка
- Разделять доступ на всех уровнях. Не из-за безопасности, а чтобы по ошибке не порушить на боевой.
- Автоматизировать задач по поддержке. То есть специальные действия — не руками, а спец.интерфейсами доступнымпи поддержке.
- Анализ поддержки — устранять причины часто возникающих проблем
Минимальный набор
- исключения — throw
- автоматический накат обновлений
- автобекапы — и не забыть проверить, что восстанавливается
- разделение доступа: база данных, ОС, сама система логины
- при интеграции — логи запрос-ответ, промежуточные
- контракты где уместно
- уведомления о сбоях
- аварийные каналы данных
- инструментарий решения задач поддержки
В заключении была рекомендация книги Michael Nygard — Release It!
