#career #softskills

Советы для CDO - Part #1
Обзор книги Carruthers, Jackson - The Chief Data Officer's Playbook

Прочитала CDO Playbook и хочу поделиться моментами, которые показались интересными.

В целом в книге ну очень высокая доля воды относительно полезной информации, поэтому обзор может быть полезным :-)

Итак, что - по мнению авторов - важно понимать, если вы CDO.

Общее - про выстраивание работы в целом:

- Не бывает много коммуникации: прогресс, фидбек, объяснения. Ты не обязательно должен делать работу в совершенстве, но все должны быть в курсе о том, что ты делаешь.

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

- Для успеха надо вовлекать людей в активности, и особенно искать евангелистов своих идей в бизнесе. Много маленьких поддерживающих армий лучше одной большой. Это становится очень важным при внедрении изменений: одна коммуникация на всех про новые правила не приведёт к результату. Много индивидуальных коммуникаций и продажи своих идей с учётом особенностей и интересов стейкхолдеров даёт сильно больше результата. И развивается и помогает в долгосрочном периоде.

- Важно не увлекаться the empire-building trap. Дело, в первую очередь, не только в том, сколько у вас людей, а в том, какое value вы можете принести.

- Лучше недокоммититься и принести больше, чем наоборот. Это должно быть в основе. Такая вот непреложная истина 😄

Про роль CDO и немного про дата офисы:

- Авторы выделяют два основных типа CDO с точки зрения их роли в компании: first CDO и second CDO. FCDO это risk-averse чувак (фундамент пирамиды), а вот SCDO - это value-add чувак (монетизация данных). Первый должен выстроить технологический и архитектурный фундамент + запустить процессы data governance, но и не забыть про квик вины, ибо ожиданий у бизнеса от роли будет много, так как инвестируют в неё тоже много. Второй CDO - больше рискует и очень плотно общается с бизнесом, а бизнес по идее уже понимает на опыте первого CDO, что от улучшения технологий можно подвинуть границы возможного.

- Нужно понимать, какого типа ты CDO, какие навыки в тебе сильнее. Как минимум, технические (и какие), навыки управленца, бизнес-ориентированности и понимания бизнес-процессов. Слабые стороны нужно подкреплять союзниками и наймом людей. И постоянно анализировать, всё ли ок. Нельзя предавать себя. Стоит понимать, кто нужен организации, и идти туда, где будут применяться твои сильные стороны.

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

- Data literacy. Обязательно должна быть база по данным у всех - понимание данных, способность их правильно понимать, уметь интерпретировать и аргументировать свою точку зрения по ним. В компании чаще всего есть значительный слой data unaware людей. В них кроется золотая жила, CDO нужно работать с ними. Они могут дать много value и идей использования данных, когда получат базовый уровень грамотности данных. При этом нужно учитывать, какой уровень грамотности нужен на каких уровнях: операционная деятельность, тактическое принятие решений, стратегическое принятие решений. На операционном важно уметь быть информированным, уметь читать данные, т.е. иметь базовые навыки. На тактическом и стратегическом нужны более индивидуальные программы обучения, плюс обязательно совместная работа с CDO над вовлеченностью к работе с данными - зачем мы это делаем, что можем классного получить.
Важно мониторить и работать над тем, чтобы на всех уровнях развивать нужную степень грамотности данных, и их использования. Плохо, когда на стратуровень поступают классные выверенные данные, но не используются, и плохо, если используются невыверенные.

Вот такие заметки. Будем рады обсудить в комментариях ваши мысли.

Во второй части обзора напишу про рекомендации для бизнеса - как найти себе подходящего CDO.

Ваш @Reliable ML

#business #обзор_книги #cdo

Как поймать прод, если он падает?

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

Сегодня разберем, что делать, когда инцидент уже просходит, и, например,
- у сервиса отпал регион
- трафик на платформу клиент перестал фильтроваться
- произошел резкий скачек QPS входных запросов, ваш кластер машин не вывозит
- latency резко увеличился и не хочет уменьшаться etc.

1️⃣ Для начала, сразу после того, как вам пришло уведомление, или вас пинганул менеджер, оцените ущерб (или по-модному blast radius). Для таких целей у вас должен быть доступ в аналитическую БД, куда аггрегируются ивенты (по аукционам, пользователям, минутам, регионам), и где вы можете, написав SQL запрос, оценить, на каком регионе, клиентской DSP, сегменте пользователей имеет место инцидент. А еще лучше для таких целей иметь уже готовый дашборд с основными аггрегатами и группами.

2️⃣ После того, как оценили ущерб, определяем состояние сервиса:
- operational: работает, возможно с небольшой долей ошибок
- degraded performance: значительная доля ошибок, ухудшен пользовательский опыт, ухудшено качество ML моделей, но основные сценарии работают или резервные (fallback) модели подхватили трафик
- partial outage: часть функционала отпала, отпал регион, полностью не отправляются запросы на конкретные DSP
- major outage: все полегло

После того, как оценили состояние, эскалируем инцидент своему менеджеру и команде инфры

3️⃣ Локализуйте проблему. Постарайтесь определить, из какого сервиса происходит причина инцидента. Если причина на сервисе, куда вы ранее не контрибьютили, пингуйте соответствующие команды, чтобы они подключились и проверили свои зоны ответственности.

4⃣️️️️️️ Пока ищется причина инцидента сфокусируйтесь на том, чтобы оживить прод (по-модному stop bleeding) - проверьте, какие были крайние коммиты, связанные с ошибками, и откатите их.

Если проблема в новых артефактах, которые кеширует сервис, то зачистите кеш (если у вас есть доступ) и перезалейте рабочие или fallback артефакты.

Если проблема в повышенном использованием CPU/ RAM от выброса трафика, upscal'ите машины на кластере

Детально исследовать, что именно привело к инциденту можно уже после - когда проблема решена.

5️⃣ Если все разрешилось - продолжайте мониторить и составьте postmortem. В нем укажите
- Оцененный ущерб
- Проанализируйте причину, почему так произошло
- Укажите ваши действия, и в какие сроки вы их предприняли

Что делают в это время менеджеры и аналитики?
- помогают связаться со стейкхолдерами (чтобы те были в курсе происходящего и могли со своей стороны что-то сделать - например, включить fallback) или нужными командами разработки
- смотрят на метрики и помогают оценить ущерб и в целом состояние приложения
- помогают эскалировать в нужную команду

Также рекомендую хорошую статью, как поднимают упавший прод на Ozon'е

Полезная статья, вынесу пожалуй в отдельный пост

https://habr.com/ru/companies/piter/articles/853400/?utm_source=habrahabr&utm_medium=rss&utm_campaign=853400

#ml #dl #competition

Пока мы готовим новую лекцию, у вас есть уникальная возможность посмотреть разборы соревнований, в которых я(Слава) участвовал. В каждом видео есть кусочек теории, секреты и приемы

1) Егэ по русскому это было мое первое соревнование с которого начался мой путь в светлое будущее. Можете умилиться, как неправильно я произношу Bert. От начала изучения питона и мл до этого соревнования прошло 3 месяца. В рамках него я изучал nlp

2) Прогнозирование короны второе соревнования. Тут я впервые столкнулся с деревьями, бустингами, табличками и понял, что это не мое. Так же погрузился в изучение визуализации и EDA

3) Потом я перешел на kaggle и первое соревнование было по звуку. Тут емко содержится теория по аудио и приемы, которые я использовал. Золото этого соревнования дало мне понять. что бояться ничего не надо(кроме ос)

4) Ну и замыкаем еще двумя соревнованиями, и снова по NLP. Первое - оценка сложности текста. Второе - извлечение сущностей. Каждое дополняет другое и глубже погружает в NLP

Приятного просмотра!