Аннотация
- Докладчик
- Антон Белоусов
Любые новые возможности продукта — это новые проблемы. Проблемы могут возникнуть в любой момент работы кода — и при первом отладочном запуске, и через годы эксплуатации: внешние сервисы перестают работать, пользователи портят данные и т.п. Полностью их не избежать, но можно подготовиться, чтобы не тушить пожары.
Что для этого нужно:
- Выработать общий подход — «чутье заднего места»: предвидение проблем + требования и принципы разработки, помогающие их предотвратить.
- Использовать каталог паттернов — уже освоенных и решенных проблем, чтобы ими чутье не перенапрягать: при разработке сверяться с ним.
Структура паттернов:
Источник проблемы — проблема — решения и меры.
Простейшие примеры источников проблем:
- Внешний источник данных (падает, портит данные),
- Пользователь (ошибается, портит данные),
- Релиз (обновление все рушит, портит данные; бета-версия конфликтует с основной, ...).
Видео
- Скачать
http://ftp.linux.kiev.ua/pub/conference/peers/addconf/2011/2ba-developers-gut-feeling-belousov.avs.avi
Для этого доклада нужен подкаст (аудиозапись)?
Примечания и отзывы
довольно неплохое, но абсолютно бесполезное выступление Антона Белоусова с банальностями на тему необходимости выработки минимального процесса выпуска продукта. Презентация хорошая, но для другой аудитории, мне кажется. ©
Антон вырос от разработчика до менеджера проектов, это был его первый доклад на конференции и удачный. Большинство участников в этот слот пошли слушать доклада Орлова и Панкратова, с которыми я знаком по различным конференциям, и потому решил послушать неизвестного мне докладчика. И не пожалел.
Доклад, по сути, представляет собой некоторый список мест, где в проекте потенциально могут быть грабли и, чтобы проект был успешным, на эти места следует обращать внимание. Неизвестных для себя мест я не обнаружил. Однако, по мере рассказа вспоминал, что о некоторых из них — рассказывал новым разработчикам. А списка в компании — нет. Приведенный в докладе вполне можно взять за основу, потому что все пункты — по делу. Ну и кто-то вполне может обнаружить и новое. неизвестное для себя.
Основные места, в которых возникают грабли.
- Пользователи — они могут портить даные из-за ошибок в системе.
- Интеграция с внешними сервисами
- Работа после наката обновлений
Сбои — потери — разгребание проблем.
Как избежать?
- Типовые проблем — типовые решения. Их надо знать и делать (бэкап, например)
- Новые проблемы — будут всегда, тут типовых решений нет. Но можно подготовиться — средства диагностики и средства восстановления. Восстановление — более-менее универсально и не зависит от конкретной проблемы.
Кто отвечает за это? Разработчик. А то он будет и расхлебывать.
Что такое «заднее чутье»?
- Источники: Люди, ПО, Железо, Процессы
- Возможные проблемы
- Решения для них
- Проверка, что решения работают (например, из бэкапа — можно поднять систему). Это — важно.
Прототип системы: нужен минимум — диагностика. В первой боевой версии — желателен максимум защиты. И далее надо постоянно поддерпживать
Дальше много частных решений.
- Таких как мониторинг или бэкапы.
- Протокол взаимодействия при интеграции; Проверка по контрактам входа-выхода
- Повторение запросов, рассчитывать протоколы на это.
- Резервные каналы синхронизации. Ннапример, с мобильного девайса, когда штатно не получается.
- Вести логи, уметь их передавать.
- Изоляция внешней системы — шлюз.
Работа с пользователем.
- Механизмы восстановления. Напрмиер при ошибочном удалении или редактирвоании
- Предусматривать возможность срезать углы, позволяя нарушать правила. Например, сохранять неконсистентные черновики.
- Сохранять простой вариант UI
- Обработчик ошибок верхнего уровня. Пользовательская диагностика. Интерфейс пользователя дляы ошибок.
- Глюки из-за проигнорированной ошибки: Кидайте исключения, а не код возврата. Проверяйте контракт.
- Уведомлять разработчика автоматически, отслеживать действия пользователя.
- Изолировать объекты разных пользователей (usec-spec)
Релиз
- Автоматический накат по одной кнопке
- Блокировать работу на время релиза.
- Порча базы патчами: бэкапы до и после, сравнение базы до и после, альфа-тест на отдельной площадке.
- Бета-тестирование — использование новой версии частью пользователей в продакшн, пока остальные на старой версии
Поддержка
- Разделять доступ на всех уровнях. Не из-за безопасности, а чтобы по ошибке не порушить на боевой.
- Автоматизировать задач по поддержке. То есть специальные действия — не руками, а спец.интерфейсами доступнымпи поддержке.
- Анализ поддержки — устранять причины часто возникающих проблем
Минимальный набор
- исключения — throw
- автоматический накат обновлений
- автобекапы — и не забыть проверить, что восстанавливается
- разделение доступа: база данных, ОС, сама система логины
- при интеграции — логи запрос-ответ, промежуточные
- контракты где уместно
- уведомления о сбоях
- аварийные каналы данных
- инструментарий решения задач поддержки
В заключении была рекомендация книги Michael Nygard — Release It!
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
