Менять компанию, в которой вы уже гуру на своей позиции, всегда стрессово. Давайте разберёмся, как не превратить первые месяцы в chaos engineering.
Фундаментальные принципы для начала:
Смиритесь: первые полгода вы не будете понимать, как устроена большая часть системы. И это нормально.
Не пытайтесь сразу всё решить: ваша цель — сначала понять, почему тут всё работает и не падает. Даже если никто этого не знает.
Вопросы важнее решений. Ваша главная задача на старте — понять, как всё работает, а не переделывать, даже если не нравится. Задавать вопросы важно. А задавать правильные вопросы ещё и полезно для ускорения онбординга.
Что делать в первые дни
1. Соберите свой mindmap:
Узнайте, какие части системы наиболее важны для бизнеса.
Определите ключевые компоненты: микросервисы, базы данных, очереди, etc.
Поймите, кто главный эксперт по каждой области (читать: к кому бегать с вопросами).
Нарисуйте общую схему архитектуры. Она будет неточной, но хотя бы задаст контекст. Если повезёт, то схема уже есть и не одна. Она наверняка будет устаревшей, но позволит по верхам вникнуть в структуру команды/департамента/компании (в зависимости от детализации схемы).
2. Изучите мониторинг и алерты:
Проверьте, что и чем мониторится.
Найдите дашборды, алерты и метрики. Даже если они плохо работают, это покажет, как команда видит систему.
Постарайтесь понять, что вызывает боль (например, false алерты или отсутствие критичных метрик).
3. Вопросы, вопросы, вопросы:
Задавайте их постоянно: «Почему так?», «Как это устроено?», «Что происходит, если это падает?», «Кто получает по шапке за простои?»
Поймите, что важно для команды и бизнеса, чтобы расставить приоритеты.
Что НЕ делать:
Не лезьте в рефакторинг. Вы пока не знаете всех последствий. Лучше наблюдайте.
Не переделывайте мониторинг. Если даже кажется, что всё ужасно, не спешите. У системы могут быть неявные зависимости.
Не критикуйте существующую архитектуру. Это точно вызовет сопротивление со стороны людей, которые всё это строили годами. Сначала разберитесь в контексте.