Персональные инструменты
 

Заднее чутье разработчика, или как избежать проблем эксплуатации? (Антон Белоусов, ADD-2011)

Материал из CustisWiki

(перенаправлено с «2ba-developers-gut-feeling-belousov»)
Перейти к: навигация, поиск

Аннотация

Докладчик
Антон Белоусов
  • twitter:antonbelousov

Любые новые возможности продукта — это новые проблемы. Проблемы могут возникнуть в любой момент работы кода — и при первом отладочном запуске, и через годы эксплуатации: внешние сервисы перестают работать, пользователи портят данные и т.п. Полностью их не избежать, но можно подготовиться, чтобы не тушить пожары.

Что для этого нужно:

  1. Выработать общий подход — «чутье заднего места»: предвидение проблем + требования и принципы разработки, помогающие их предотвратить.
  2. Использовать каталог паттернов — уже освоенных и решенных проблем, чтобы ими чутье не перенапрягать: при разработке сверяться с ним.

Структура паттернов: Источник проблемы — проблема — решения и меры.

Простейшие примеры источников проблем:

  • Внешний источник данных (падает, портит данные),
  • Пользователь (ошибается, портит данные),
  • Релиз (обновление все рушит, портит данные; бета-версия конфликтует с основной, ...).

Видео

Скачать
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».