Скажи развитию "Да!". Часть 2. Инструменты и технологии.

"Не изобретайте велосипед, нагуглите его в интернете"
Аня Чуркина.

Помогите мне развиваться!

Оставляйте обратную связь в комментариях!

Откуда ноги растут?

Мы поговорили про ценности и векторах развития в Части 1. Пришло время для самого вкусного - инструментов!

Прежде, чем окунуться в море возможностей, хочу объяснить идею своего подхода. Не изобретайте велосипед, нагуглите его в интернете. Чтобы первый шаг был действительно простым, я подготовила для вас cookbook. Для каждого тезиса я дала ссылки на гайды, проекты в git-hub, онлайн-тренажеры, и даже предложила свои фреймворки, которые вы можете переиспользовать. Ссылки по ходу

Теперь ныряем с головой!

Инструменты, технологии, фреймворки

База знаний

Для создания крутой базы знаний воспользуйтесь алгоритмом:

1. Проведите ревизию существующих документов
2. Типизируйте документы
3. Разработайте шаблон для каждого типа
4. Разработайте ролевую модель [Опционально]
5. Разработайте модель поиска [Опционально]
6. Заручитесь поддержкой коллег и внедрите наработки

Предлагаю свой фреймворк шаблонов https://github.com/AnkaChurkina/knowledge-base-templates

Критерии работоспособности

1. Зафиксируйте метрики
2. Определите критерии
   Примеры метрик и критериев можно посмотреть по ссылке https://github.com/AnkaChurkina/performance-criteria-sample
3. Обеспечьте данные для анализа
   Проведите ревизию БД и логов, убедитесь, что вы можете полностью проследить и позитивные, и негативные сценарии.
4. Инициируйте развертывание средств мониторинга.

• Kibana
• Grafana
  - https://github.com/yesoreyeram/grafana-dashboards
  - https://github.com/bluetom520/ZABBIXAPI
• Zabbix
  - https://github.com/jjmartres/Zabbix
  - https://github.com/thecamels/zabbix
• Qryn
• Xymon
  - https://github.com/drahamim/Xymon-tools
  - https://github.com/nlienard/xymon-external

5. Нарисуйте дашборды и начните мониторить состояние здоровья сервиса

Troubleshooting

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

1. Сформируйте образ сервиса

- Определите критерии работоспособности и поставьте сервис на мониторинг

- Определите ответственных (саппорт, разработка)

- Контакты должны быть в общем доступе для оперативной связи

- Ответственным сотрудникам должен быть обеспечен доступ к test и prod системам для оперативных действий. В текущих реалиях в том числе удаленный.

2. Создайте скрипты и инструкции для работы по типовому случаю

Например, сработала ошибка “Используется неверная версия входящего файла”, опишите:

1. Установить проблемного клиента

2. Связаться с клиентом

3. Предоставить клиенту ссылку на актуальную версию файла

3. Разработайте стратегии работы с нетиповыми случаями.
Очень хочется пополнить список с вашей помощью, оставляйте комментарии!

- Так не должно быть, но... Одно битое сообщение способно поставить колом весь сервис. Будьте предупредительны, предусмотрите входные фильтры  - json, xml, заголовки, параметры, url, методы, ip.

- Предусмотрите возможность “отбивать” сообщения, чтобы высокая нагрузка не положила сервис. Например, пропускать только 100 000 tps при входной нагрузке 500 000 tps. Лучше обслужить 20% клиентов, чем не обслужить никого.

- У вас всегда должна быть наготове и оттестирована инструкция по откату версии. БД всегда должна обеспечивать совместимость старой и новой версии ПО.

- Научитесь проводить разбор методом “5 почему”. Отличный способ попрактиковать его во время ретроспективы инцидентов.

- Перед выпуском версий тестируйте логи, в них должно быть необходимо и достаточно информации.

4. Разработайте меры для оперативного прекращения/минимизации действия инцидента

5. Разработайте и, самой важное, внедрите меры по недопущению

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