Коллеги! Объявляю набор 4х модераторов.

Максим Цепков @MaximTsepkov  написал конспект по выступлению Евгений Потапов @eapotapov на #SaintHighLoad2019 про мониторинг сложных систем в 2019 году. Что изменилось и как не пропустить проблему?

Основное сообщение доклада -  90% мониторинга - это кодинг, а не установка каких-то инструментов с их настройкой. И потому это требует проектирования, планирования и разработки, требует участия программистов, а не только админов. Эта ситуация сложилась постепенно, 10 лет назад были приложения в БД и сервер приложений интернет-магазина, и их действительно можно было мониторить, развернув и настроив Zabbix. А в 2010 уже надо мониторить нагрузку, проверять, что поисковый движок работает и индексирует, что в в каталоге попали все товары, прохождение доставки, которая во внешней службе, работа sms-сервиса, и надо было уже писать много скриптов мониторинга, но все равно сохранялось обозримое количество приложений. Дальше пришли микросервисы и кластеры, и ситуация еще усложнилась. А в голове у тех, кто планирует проекты, все равно "поставь и настрой софт, пусть не zabbix, а prometheus + Grafana + плугины, и все, мониторинг сработает". А реально 90% мониторинга - это написание кода.

Я от себя хочу заметить, что раньше тоже полноценный мониторинг бизнес-сценариев, о которых шла речь в докладе, zabbix все равно не гарантировал. Просто тогда всем было понятно, что это надо предусматривать внутри приложения, это не рассматривали как часть мониторинга. А сейчас, поскольку приложение из кусочков, есть ложное впечатление, будто это тоже может получить.

Ну а дальше доклад был о том, что в этот проект входит, как его организовывать. Мониторинг включает бизнес-логику приложения, health-метрики сервисов, интеграционную логику,  инфраструктур и приложение как инженерный продукт. Аллертинг - его надо делать сразу, не после мониторинга. Иначе узнаем все равно по звонку пользователя. И он включает не только оповещения, но и систему дежурств и эскалации, и еще базу знаний по инцидентам.

И разные технические подробности и боли. Кто придумал Prometheus внутрь кубика? Кластер упал - как разбираться будете? Да, изнутри тоже надо, но надо и снаружи смотреть. Внешние проверки работоспособности должны обращаться снаружи - проблемы доступности вашего сервера надо диагностировать. А еще мониторинг мониторинга оже должен быть.

По инструментам - по сути уже есть отраслевые стандарты Prometheus + Grafana - стандарт + логи на ELK-стек + Jaeger (Zipkin) для АРМ и трейсинг. Но! Инструменты после задачи и для нее, а не наоборот. Потому что разные инструменты - для разного. Никто не начинает решать задачу "разработай приложение" поднимая базу данных, а начинают проектировать архитектуру. В том числе - выбирая базу данных. А сейчас DeevOps начинают именно с установки инструмента, а потом начинают налаживать мониторинг инфраструктуры, чаще всего не потому, что это болит, а потому, что это - понятная им задача.

Обсудить за мониторинг здесь: t.me/ctorecordschat

Традицонный ежегодный чек-ап. Каждый пишет в своей рабочей консоли и если что-то есть, показывает здесь:

git log -p | grep сиськи

Написать результаты здесь: http://t.me/ctorecordschat

- Привет, Дим. Слушай, хочу на скрам-мастера подучиться, получить сертификат - не подскажешь, где лучше это делают?
- Даров! Тебе надо вот к нему: https://www.facebook.com/illya.pavlichenko (cкажи, что его порекомендовала Марина Симонова @MarinaAAlex (моя однофамилица, не родственница)).

П.С. этот пост не является рекламой, ни как ни кем не оплачен

* * Рекламный пост * * Пост проплачен * *

Мы все хотели бы нанимать в команду толковых ребят и знаем, что на рынке идёт битва за таланты, GetIT уже второй раз проводит конференцию о том, как и где искать таланты, как автоматизировать свою работу и построить бренд в IT.

Я думаю вам, как заказчикам, было бы интересно отправить своих рекрутеров на прокачку на практическую конференцию про IT-рекрутмент. Да и многим лично будет интересно, так как  💯 процентов успеха люди добиваются только в лучших командах.

Подробности на сайте: http://bit.ly/2U93Uql
А вот тут статья про боли в IT рекрутменте: http://bit.ly/2Ue3rmG

По промокоду CTORECORDS офлайн билет можно купить со скидкой 2000 руб.

Аудит. Часть 1.

Первое, что надо сделать, - это определиться с терминологией:

1. Термины
   1.1. Аудит - обучение Дмитрия Симонова
   1.2. 121 - это ван-ту-ван, беседа с глазу на глаз
   1.3. ретра - это когда все собираются и думают, как жить дальше
   1.4. синк - это когда обсуждаешь с кем-то тему до состояния, когда вы думаете про неё одинаково

Аудит - штука стрессовая для всех. И происходит он на чужой территории, - поэтому надо тщательно всё разведать и выяснить:

2. Подготовка
   2.1. Ты выдаёшь доступы к системам трекинга и обсуждений
      2.1.1. Перечень трекеров
         2.1.1.1. JIRA или другой трекер задач
         2.1.1.2. Gitlab или другой трекер кода
         2.1.1.3. Toggl или другой трекер времени, если используется
      2.1.2. Я подключаю свой агрегатор для получения агрегированные worklog-ов в реалтайме в разрезе каждого члена команды
      2.1.3. Ты делаешь сквозную выборку по всем сообщениям в слаке за последнюю неделю по каждому сотруднику.
      2.1.4. Я собираю данные для 121 по
         2.1.4.1. По кодовой базе
         2.1.4.2. По подходам к использованию стореджей
         2.1.4.3. По используемой архитектуре
         2.1.4.4. По ворклогам
   2.2. Ты пишешь по каждому члену команды первичные данные:
      2.2.1. ФИО
      2.2.2. возраст
      2.2.3. женат/замужем за работающим/безработным
      2.2.4. количество, возраст и пол детей, 
      2.2.5. статус по жилью (с родителями, арендует сам, арендует вместе с кем-то, ипотека, в собственности)
      2.2.6. Позиция в команде
      2.2.7. Когда и как пришёл
      2.2.8. Кто именно его собеседовал
      2.2.9. Кого он считает нанимателем (от работодателя отличается тем, что с ним он договорился про деньги и он объявил ему, что он принят)
      2.2.10. Профессиональные интересы
      2.2.11. Успехи на работе
      2.2.12. Поднималась ли ему зп? почему? при каких обстоятельствах?
      2.2.13. Факапы на работе
      2.2.14. Витающее мнение команды о нём
      2.2.15. Твоё мнение о нём
      2.2.16. Что известно про его жизненные планы (собирается жениться, уехать в Канаду, и тд и тп)?
      2.2.17. Чего ожидаешь от него Ты и непосредственный руководитель?
      2.2.18. Перечень артефактов от него:
         2.2.18.1. видео
         2.2.18.2. документация его авторства
         2.2.18.3. выборку сообщений от него в слаке за последний месяц
   2.3. Я читаю все собранные артефакты из пп1 по каждому сотруднику
      2.3.1. мы обсуждаем каждого сотрудника, 
      2.3.2. фиксируем самое интересное из того, что он может рассказать и нам это важно.

Аудит. Часть 2.

Теперь необходимо приготовить команду к взаимодействию со мной и мягко разрешить со мной общаться, не боясь рассказывать самые заковыристые случаи. Ни у кого не должно возникнуть никаких предубеждений или подозрительности.

Как это в принципе можно подать? Только одним способом, - когда не я оказываю услугу компании, а она - мне. Компания обучает меня чему-то и делится со мной чем-то. Значит и результаты обучения будут влиять только на меня самого. Нет и не может быть никаких результатов в компании-учителе. Нечего бояться. Некого бояться.

Очень важно, что обучает компания не кого-то а известно признанного основателя техдирского канала, - Дмитрия Симонова.

Это схема позволяет выиграть всем.

3. Начало (светлая сторона силы)
   3.1. Ты проводишь беседу с командой
      3.1.1. Дмитрий Симонов обучается у вашей компании, как действительно надо работать. 
      3.1.2. Он систематизирует общие подходы к работе и хочет перенять лучшие методики именно у вашей компании. 
      3.1.3. Хочет использовать их в своей деятельности на примере одной из ваших лучших команд.
   3.2. Ты проводишь беседу с каждым (!) членом команды
      3.2.1. объясняешь, что мы уже сотрудничали с Дмитрием
      3.2.2. он был буквально счастлив приобщаться к тем знаниями, которыми с ними поделилась такая-то команда (даёшь ссылку на видео или какие-то материалы; можно показать ссылку на видео с моими 4мя кейсами разработки)
      3.2.3. Рассказываешь, что было бы совсем идеально, если бы ты рассказал самую мякотку по таким-то и таким-то темам (как раз тем, про которые мы с Тобой обсудили).
   3.3. Ты устраиваем общий созвон всей команде со мной
      3.3.1. в котором Ты представляешь меня
      3.3.2. ещё раз рассказываешь о том, что компания согласилась проконсультировать меня по образцам лучшей в России разработческой компании. 
   3.4. Я кратко рассказываю команде
      3.4.1. кто я такой, 
      3.4.2. чем занимаюсь вообще, 
      3.4.3. какой у меня опыт
      3.4.4. рассказываю, какой порядок нашей дальнейшей работы
      3.4.5. отвечаю на возникшие вопросы. 
   3.5. Я даю каждому сотруднику заполнить простейшую анкетку персонально:
      3.5.1. Что тебе удалось сделать/создать/сотворить? Какими результатами ты гордишься?
      3.5.2. Что тебя больше всего мотивирует в работе, чем интересно заниматься?
      3.5.3. Чем бы Ты хотел заняться ещё кроме своих непосредственных обязанностей?
      3.5.4. Какие твои имеющиеся качества/навыки/умения не используются в командной работе? И почему?
   3.6. По каждому из его коллег в анкетке будут вопросы:
      3.6.1. Где в профессиональном плане можно опереться на вашего коллегу?
      3.6.2. Где к командной работе можно опереться на вашего коллегу?
      3.6.3. Где в человеческих отношениях можно опереться на вашего коллегу?
      3.6.4. Какие из тех вещей, которым учится коллега, Тебе самому пригодились бы и Ты тоже уже начал их изучать?

Накопленные результаты надо flush-нуть:

4. Синхронизация
   4.1. Голосовой созвон обсуждение с Тобой результатов по пп 3
   4.2. Техническое собеседование каждого сотрудника проводится с заведомым авторитетом по выбранному стеку (у меня есть все или почти все специальности).
   4.3. 121 с каждым сотрудником 
      4.3.1. по результатам анкетки
      4.3.2. выявление тем для обсуждений на всех. 
      4.3.3. используемые технические архитектурные решения
      4.3.4. коллеги, как очень интеллектуальный инструмент: кто где и в чём может помочь в решении каких задач?

Аудит. Часть 3.

5. Анонимная часть (тёмная сторона силы)

В этой части речь пойдёт о противоположности каждого члена команды, - о его слабостях, - т.н. точках роста.

Что это такое? Это то, благодаря чему и Ты и компания приобрели сотрудника. То, благодаря чем, вообще возможно с ним работать. Если в пп 2, 3 и 4 речь шла о том хорошем, что компания приобретает, то в пп 5 речь идёт о том, чем компания расплачивается (кроме прямых и косвенных финансовых трат) за работу сотрудников.

То есть компания получает сильные стороны  сотрудников и расплачивается с ними за готовность принимать его слабые стороны. Причём это именна та часть, где расплачиваться приходится не компании, а непосредственным руководителям, - именно они принимают решение, отпустить ли сотрудника, когда ему очень надо убежать посидеть с ребёнком. Или возможно он этим прикрывается, а у него есть некие заботы. о которых он рассказывать не готов. Чем лучше руководитель тут понимает сотрудника, тем точнее происходят расчёты с ним.

В этой части работы все анкеты абсолютно и гарантированно анонимные. Результаты заполнений доступны только мне лично, так как только такой подход гарантирует хоть какую-то адекватность сбора данных.

   5.1. Общая часть (если человеку сложно писать, сразу проговариваем голосом на 121):
      5.1.1. С какими проблемами тебе пришлось столкнуться в последнее время?
      5.1.2. Что или кто мешает тебе получать удовольствие от работы в компании?
      5.1.3. Чего мы не делаем из того, что должны?
      5.1.4. Будь ты на моем месте, что бы ты изменил в отделе/компании?
      5.1.5. В чем состоит основная потенциальная возможность руководителя/команды/компании, которую мы, по твоему мнению, упускаем?

По каждому сотруднику будет отдельна анкета для фидбека ему самому от его коллег, доступ к данным которой будет только у меня и у сотрудника. Заполнение анкеты будет абсолютно анонимным. Результаты будет получать сотрудник и я.

   5.2. В анкете будут вопросы про этого коллегу:
      5.2.1. Где в профессиональном плане вы, к сожалению, не можете опереться на вашего коллегу и на него лучше не надеяться?
      5.2.2. Где в командной работе вы, к сожалению, не можете опереться на вашего коллегу и на него лучше не надеяться?
      5.2.3. Где в человеческих отношениях вы, к сожалению, не можете опереться на вашего коллегу и на него лучше не надеяться?
      5.2.4. Чему вашему коллеге стоило бы поучиться или прокачаться?

Аудит. Часть 4.

И начинаем подводить итоги:

6. Промежуточный итог
   6.1. Беседа, синк с Тобой:
      6.1.1. Обсуждение результатов по пп 4, 5 и 6 (рез-ты пп. 6 без раскрытия авторства)
      6.1.2. Синхронизация по пониманию каждого сотрудника, - мы должны думать про каждого из них одинаково
      6.1.3. подготовка к совместной ретре
   6.2. Синк с командой
   6.3. Совместная ретра

Теперь много-много разговоров:

7. Серия итоговых бесед с каждым из сотрудников 
   7.1. Обсуждением целей для каждого из них на ближайшие полгода и плана по их достижению.

И зафиксировать результат. Если этого не делать, считай время и бабло зря потратили:

8. Фиксация
   8.1. Итоговая беседа с Тобой с обсуждением целей для Тебя и плана по их достижению.
   8.2. Каждые два месяца контрольный созвон с каждым из сотрудников, промежуточные итоги достижения целей.
   8.3. Через полгода, - оценка достигнутых результатов и подготовка к новому аудиту.

Обсудить за проводимые аудиты тут: http://t.me/ctorecordschat

Задать вопрос Симонову про аудиты или что-нибудь ещё здесь: https://forms.gle/i2kvJcZ3h9vofwhW8

Задать вопрос Симонову: https://forms.gle/i2kvJcZ3h9vofwhW8

Крутая, тема, всем советую! Я вот обсудил свои насущные вопросы и теперь картина передо мной стала яснее) Дима очень отзывчив и всегда рад помочь. Да чего там, просто всегда приятно пообщаться с умным человеком. Главное приходите с какими-то конкретными вопросами, чтобы получить максимум результата от созвона, встречи, переписки)

* * Рекламный пост * * Пост проплачен * *

Про Кубер

Чтобы победить проблемы монолитов, придумали микросервисы. Чтобы победить проблемы микросервисов, придумали Docker. Чтобы победить проблемы Docker, придумали Kubernetes.

Одна из проблем Kubernetes — сложность. «Вы просто не умеете его готовить». Southbridge придумала Слёрм, трехдневный интенсив, где мы учим администраторов и разработчиков правильно готовить Kubernetes.

Базовый курс для тех, кто впервые видит Kubernetes, пройдет 27-29 мая, а продвинутый — с 31 мая по 2 июня.

Цена двух курсов (70 тысяч) сравнима с ценой консультации у хорошего архитектора Kubernetes.

Мы пригласили Дмитрия Симонова на оба курса. У всех, кто присоединится, будет возможность проконсультироваться у Дмитрия и у спикеров Слёрма, а заодно пообщаться с теми, кто уже перешел на Kubernetes или только планирует.

По промокоду CTORECORDS скидка 5%.

https://slurm.io/?utm_source=ctorecordschannel

Вот тут фоточки с предыдущего слёрма: https://www.facebook.com/ctorecords/posts/10155878390262504