gitinsky

В Git in Sky мы последние полтора года плотно занимаемся безопасностью AI-контуров: аудируем интеграции, разбираем архитектуру доступов, помогаем командам выстроить нормальный контроль над тем, что происходит между их данными и языковыми моделями.

За 2025-2026 годы произошло достаточно публичных инцидентов с AI, чтобы написать большую статью. И призвать всех, кто работает с AI-решениями, обращать внимание на безопасность.

Масштаб: что говорит статистика

По данным IBM Cost of Data Breach Report 2025 , 13% всех корпоративных утечек в прошлом году прошли через AI-системы или AI-интеграции. Средняя стоимость одного такого инцидента $4.88 млн. OWASP в своём обновлённом топе угроз для LLM-приложений поставил prompt injection на первое место LLM01:2025. По оценкам Lakera , 73% задеплоенных AI-агентов в 2025 году уязвимы к тому или иному виду инъекций.

Громкие инциденты

DeepSeek: открытая база с миллионом чатов

Январь 2025

Wiz Research обнаружили, что у DeepSeek открыт ClickHouse-инстанс без аутентификации по адресам oauth2callback.deepseek.com:9000 и dev.deepseek.com:9000. Через веб-интерфейс можно было выполнять произвольные SQL-запросы. CTO DeepSeek сам признал: "это было настолько просто найти, что мы уверены – мы не единственные, кто это сделал".

Что лежало в базе: более 1 млн строк логов с историей чатов пользователей, API-ключи, детали бэкенда. Wiz уведомили компанию, база была закрыта за 30 минут после уведомления. Но к тому моменту данные уже расходились по даркнету DeepBreach слили дамп на форумах.

Почему это важно: DeepSeek пускали в корпоративную среду тысячи компаний именно в этот период у него был взрывной рост. Компании настраивали интеграции с production-системами, пока их чаты читал кто угодно с браузером.

LiteLLM → Mercor: supply chain через AI-библиотеку

Март 2026

19 марта 2026 года атакующие переписали git-теги в репозитории trivy-action, подменив релиз v0.69.4 на вредоносный. 24 марта, в 10:39 UTC, CI/CD LiteLLM запустил сборку, вытащил Trivy без закреплённой версии, и malware-экшен слил PYPI_PUBLISH токен. Через 40 минут на PyPI появились версии litellm 1.82.7 и 1.82.8 с встроенным стилером.

Вредоносный .pth-файл (litellm_init.pth, 34628 байт) запускался автоматически при каждом старте Python. За 40 минут до блокировки PyPI пакет скачали 119 000 раз. Стилер собирал: SSH-ключи, GCP ADC, AWS access keys, Azure-токены, Kubernetes configs, API-ключи из .env файлов, пароли от баз данных.

Mercor – платформа с оценкой $10 млрд, поставляет тренировочные данные для крупных AI-компаний использовала LiteLLM в production. В результате атаки утекло 4 TB данных: 939 GB исходного кода платформы, 211 GB базы пользователей, 3 TB видеозаписей интервью и документов верификации личности. Хакеры выставили дамп на продажу.

Последствия: Meta приостановила сотрудничество с Mercor. OpenAI и Anthropic начали внутренние расследования – Mercor работал с тренировочными данными обоих. Подан коллективный иск от 40 000 человек. Утекли не просто персональные данные, но и методологии разметки и тренировки моделей.

Vercel: AI-агент как вектор атаки через OAuth

Апрель 2026

Vercel – IT-инфраструктурная компания с оценкой под $10 млрд. Вектор атаки оказался неожиданным: не уязвимость в ПО, не фишинг, не вирус. Сотрудник подключил AI-ассистента к своему рабочему Google Workspace через стандартный OAuth-флоу.

Механика: AI-агент запросил стандартный набор прав: чтение почты, доступ к Drive, календарь. Сотрудник нажал «Разрешить», как нажимают обычно, и забыл. Через этот OAuth-токен атакующие вытащили переписку с production-ключами, конфиги из Google Drive и куски исходников из прикреплённых файлов.

На BreachForums хакеры выставили дамп исходников и переменных окружения Vercel на продажу за $2 млн. Официальный отчёт об инциденте опубликован на vercel.com/kb/bulletin/vercel-april-2026-security-incident.

Главный урок: Периметр безопасности Vercel строился вокруг людей, репозиториев и инфраструктуры. AI-агентов в модели угроз не было. Модель, которую сотрудник подключил на прошлой неделе, читает корпоративную почту с теми же правами, что и он сам и не увольняется никогда. Аудит AI-интеграций нужно вести как аудит доступа сотрудников: инвентаризация, пересмотр раз в квартал, отзыв токенов по умолчанию.

Средняя компания сегодня подключила десяток AI-тулов через OAuth к корпоративным сервисам. MCP-серверы держат живые токены к GitHub, Slack, Google Drive. Один скомпрометированный AI-вендор – и у атакующего Google Workspace любой из ваших клиентов.

GitHub Copilot: RCE и кража данных через prompt injection

Август 2025 

CVE-2025-53773 – удалённое выполнение кода

Критическая уязвимость в GitHub Copilot и Visual Studio Code: через prompt injection атакующий получал Remote Code Execution на машине разработчика. Эксплуатация работала через файл .vscode/settings.json – экспериментальная фича отключала все подтверждения для операций Copilot, позволяя AI выполнять shell-команды без oversight. Патч вышел в Patch Tuesday августа 2025.

CVE-2025-59145 (CamoLeak) – кража секретов без выполнения кода

CVSS 9.6. Атака CamoLeak: злоумышленник подаёт pull request с невидимыми markdown-комментариями, содержащими вредоносные инструкции. Copilot обрабатывает их и через механизм рендеринга изображений сливает API-ключи и исходный код из приватных репозиториев. GitHub тихо закрыл уязвимость, отключив рендеринг изображений в Copilot Chat. Публичного disclosure не было, исследователь раскрыл детали через 2 месяца после патча.

Взлом AI-агентов Anthropic, Google и Microsoft через GitHub

Октябрь 2025

Исследователь Aonan Guan последовательно взломал AI-агентов всех трёх компаний через их GitHub Actions интеграции. Схема – prompt injection, механизм в каждом случае разный:

• Anthropic (Claude Code Security Review): заголовок PR с payload-ом, выполнившим embedded-команды. Агент слил Anthropic API key, GitHub access token и другие секреты в JSON-ответе. Bounty: $100.

• Google (Gemini): в GitHub issue добавлена фейковая "trusted content section" после легитимного контента. Gemini переопределил safety-инструкции и опубликовал собственный API-ключ как комментарий к issue. Bounty: не раскрыто.

• Microsoft (Copilot Agent): вредоносные инструкции спрятаны в HTML-комментарии внутри GitHub issue — в отрендеренном markdown человек их не видит, AI видит. Разработчик назначил issue на Copilot Agent, бот выполнил hidden-инструкции. Bounty: $500.

Ни одна из компаний не выпустила публичный advisory и не присвоила CVE. Пользователи на старых версиях инструментов остались уязвимы.

Microsoft 365 Copilot: EchoLeak и Reprompt

2025-2026

EchoLeak (CVE-2025-32711, CVSS 9.3)

Атакующий вставляет вредоносный prompt-payload в тело письма или документа. Microsoft 365 Copilot при суммаризации обрабатывает payload, извлекает приватные данные из почтового ящика и возвращает их атакующему. Клик пользователя не нужен – достаточно получить письмо. Microsoft закрыл уязвимость на стороне сервера, пострадавших клиентов, по их заявлению, не было.

Reprompt (CVE-2026-26133)

Исследователи Varonis обнаружили: одного клика на легитимную Microsoft-ссылку достаточно, чтобы злоумышленник захватил сессию Copilot и сохранял доступ даже после закрытия чата. Атака позволяет читать почту, Teams-переписку, документы SharePoint – всё, к чему у пользователя есть доступ.

Массовые jailbreak-атаки

2025

Sockpuppeting — один вызов API, 11 моделей

Техника, сломавшая ChatGPT, Claude, Gemini и 8 других моделей одной строкой кода. Атака использует стандартную функцию API: в поток ответа модели перед её ответом инжектируется фейковая согласительная фраза ("Sure, here is how to do it:"). Модель воспринимает это как продолжение своего собственного ответа и продолжает без ограничений.

Policy Puppetry — обход через ролевое моделирование

Prompt-инъекция комбинирует "политику" и ролевое моделирование с leetspeak (замена букв символами). Обошла guardrails в Gemini 2.5, Claude 3.7 и GPT-4o. Затрагивала тематику CBRN, массового насилия и самоповреждений.

Cisco: DeepSeek — 100% success rate при jailbreak

Исследование Cisco показало: DeepSeek R1 не отклонил ни один из 50 тестовых harmful-промптов. 100% success rate джейлбрейка. В сравнении: ChatGPT 4.5 блокировал 97% попыток, Claude 3.7 Sonnet – 100%.

Контекст: именно DeepSeek в начале 2025 года активно интегрировали в корпоративные продукты как "дешёвую альтернативу GPT-4". Некоторые компании направляли через него чувствительные запросы.

Фреймворк: как систематизировать атаки на AI-агентов

В 2025 году Google DeepMind опубликовал исследование "AI Agent Traps" – систематизацию векторов атак на автономных AI-агентов. Документ описывает 6 категорий манипуляций, которые работают не через уязвимости кода, а через природу самих LLM.

1. Content Injection (инъекция контента)

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

2. Semantic Manipulation (семантическая манипуляция)

   Переформулировка вредоносного запроса через авторитетные контексты: "SYSTEM:", "[TRUST]", "Developer mode". Модель обучена следовать системным инструкциям атакующий имитирует их формат. Именно так работает sockpuppeting и policy puppetry.

3. Cognitive State Attacks (атаки на состояние)

   Манипуляции через несколько ходов диалога. Модель постепенно "соглашается" с установками атакующего, после чего выполняет запросы, которые в лоб отклонила бы. Multi-turn jailbreaks в 2025 году давали success rate выше 70% против моделей, защищённых только от single-turn атак.

4. Behavioural Control (контроль поведения)

   Инструкции, изменяющие долгосрочное поведение агента: "Когда встретишь X, всегда делай Y". Агент запоминает правило и применяет его в будущих сессиях, создавая персистентный backdoor без изменения весов модели.

5. Systemic Attacks (системные атаки)

   Эксплуатация архитектуры: RAG poisoning (отравление базы знаний агента), атаки на tool use (агент вызывает внешние API). Если агент имеет доступ к GitHub, почте, базам данных – атакующий через content injection получает эти же доступы.

6. Human-in-the-Loop Bypasses

   Атаки на подтверждения пользователя. Агент формулирует запрос на подтверждение так, чтобы пользователь машинально нажал "Да" – или использует side channels, чтобы вообще не требовать подтверждения. CVE-2025-53773 в Copilot был именно об этом: экспериментальная фича отключала все confirmations.

Аааа, что же делать, мы все умрем

Да, но позже)

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

И здесь мне кажется, что профессия DevOps переживает второе рождение. Всё, что DevSecOps-инженеры умеют делать с классической инфраструктурой – пайплайны верификации артефактов, управление секретами, политики доступа, мониторинг аномалий – напрямую переносится на AI-контур.

Это интересная ситуация, когда старая экспертиза становится дефицитной заново.

Продолжаю беседы с нашим техлидом Дмитрием. Сегодня — о том, как взлом одного npm-аккаунта за 3 часа распространил RAT на 174 000 пакетов и почему стандартные инструменты вроде NPM Audit это не поймали. Разбираем инцидент с Axios: механику атаки, слепые пятна в CI/CD и то, что реально работает.

30 марта 2026: что произошло за 3 часа

30 марта 2026 года в npm появились две вредоносные версии Axios — 1.14.1 (тег latest) и 0.30.4 (тег legacy). Axios — JavaScript-библиотека для HTTP-запросов с ~100 млн загрузок в неделю и 174 000 зависимых пакетов в npm. Фактически, если проект на Node.js — с высокой вероятностью он тянет Axios транзитивно.

Злоумышленник получил доступ к npm-аккаунту jasonsaayman — ведущего мейнтейнера библиотеки. Первый признак компрометации: email аккаунта сменился с jasonsaayman@gmail.com на ifstap@proton.me, а метод публикации изменился — с доверенного OIDC-пайплайна со SLSA-провенансом на прямой CLI-publish. Оба флага автоматически поймала Elastic Security Labs через мониторинг цепочки поставок.

Вредоносные версии пробыли в реестре около 3 часов. За это время их успели скачать и задеплоить тысячи команд — у большинства из них сборка забирает latest-версию без явного закрепления.

Как работает атака

plain-crypto-js: вредоносная зависимость

Злоумышленник не патчил код самого Axios. Вместо этого он добавил в зависимости пакет plain-crypto-js. Схема в два шага:

• plain-crypto-js@4.2.0 — «чистая» версия, опубликована заранее для создания истории публикаций

• plain-crypto-js@4.2.1 — вредоносная версия с postinstall-хуком: при установке автоматически скачивала и запускала stage-2 RAT с C2-сервера sfrclak[.]com:8000

RAT — кросс-платформенный: отдельные payload для macOS, Windows и Linux. После установки соединения с C2 — полный удалённый доступ к машине.

Почему это прошло через большинство CI/CD без остановки

CI/CD-пайплайны собирают, тестируют и доставляют обновления без участия человека. Когда команда не закрепляет конкретную версию зависимости, а указывает последнюю доступную (^1.x.x), при каждой сборке npm резолвит актуальный latest. В окно между 30 и 31 марта — это была 1.14.1 с RAT внутри.

Большинство команд не имеют в CI/CD шага, который проверяет безопасность зависимостей до сборки. По данным OpenSSF Scorecard 2024, менее 20% открытых проектов используют закреплённые хеши зависимостей. У коммерческих проектов, которые тянут эти пакеты, картина не лучше.

Почему NPM Audit не остановил атаку

NPM Audit сравнивает установленные пакеты с базой CVE. На момент атаки ни Axios 1.14.1, ни plain-crypto-js 4.2.1 не числились в базах — они были свежеопубликованы. NPM Audit сканировал их и возвращал статус clean.

Логика инструмента здесь не ломается — она просто неприменима к этому классу атак. CVE-базы фиксируют известные уязвимости. Атака через компрометацию аккаунта публикует формально новый пакет, который ещё не успел попасть ни в какую базу.

Этот инцидент поймал инструмент другого класса: Elastic Security Labs обнаружила атаку через поведенческий мониторинг — отслеживание изменений метаданных пакетов (смена email, метод публикации, новая зависимость в релизе без истории изменений).

Зависимости — новый периметр безопасности

Что сломалось в старой парадигме?

Раньше ответственность делилась по ролям: тимлид или архитектор решал, какой модуль добавить; DevOps следил за процессом доставки; безопасники подключались позже с SAST/DAST-проверками; юристы — за лицензиями. Каждый проверял своё.

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

174 000 пакетов: почему масштаб такой

Axios входит в топ-5 самых скачиваемых пакетов npm. 174 000 пакетов прямо или транзитивно зависят от него. Механика та же, что в CMS-эпоху с WordPress и Joomla: одна уязвимость в ядре — ключ ко всем проектам на этой платформе.

Стандартный Node.js-проект содержит 40–60 прямых зависимостей. У каждой из них — свои зависимости, в среднем по 5–7 пакетов. Итого: 40 × 5 = 200+ пакетов, которые молча живут в вашем проекте, и за каждым — конкретный человек с учётной записью.

Транзитивные зависимости — отдельный класс: пакеты, нужные только на этапе сборки и не попадающие в production. Они тоже могут нести угрозу и при этом вообще не попадают в фокус code review.

Как AI меняет соотношение сил

AI ускоряет написание кода, помогает с troubleshooting и делает автоматическое code review. Те же возможности работают против защитников: нейросеть сканирует чужой код на уязвимости за минуты — задача, на которую опытный специалист раньше тратил часы.

Атрибуция этого инцидента — северокорейский threat actor (по данным Google Cloud Threat Intelligence). Это уже не скрипт-кидди с форума. Государственные группы используют AI для поиска точек входа в supply chain, автоматически сканируя тысячи пакетов на слабые аккаунты мейнтейнеров.

Количество уязвимостей в open source коде, которые ещё не выявлены и не задокументированы, исчисляется миллионами. По данным исследования Google Project Zero за 2023 год, медианное время от обнаружения уязвимости до публичного патча — 25 дней. AI сокращает время поиска на стороне атакующих быстрее, чем растут команды безопасности на стороне защитников.

Что остановило бы эту атаку

npm audit signatures

Команда проверяет криптографические подписи каждого пакета и подтверждает, что публикация прошла через официальный CI/CD-пайплайн с SLSA-провенансом — а не через прямой CLI-publish с изменённого аккаунта.

В случае Axios 1.14.1 эта проверка выявила бы аномалию немедленно: смена метода публикации с OIDC на прямой CLI — явный флаг. Именно этот сигнал поймала Elastic Security Labs в своём мониторинге.

Что нужно встроить в CI/CD

• Закреплённые версии или хеши зависимостей — npm install --frozen-lockfile или использование package-lock.json с commitом в репозиторий

• npm audit signatures — проверка подписей перед каждой сборкой

• SAST на зависимости — статический анализ не только своего кода, но и устанавливаемых пакетов

• Dependabot или аналоги — автоматические уведомления об уязвимостях в зависимостях с известными CVE

• Поведенческий мониторинг пакетов — анализ metaданных релизов: смена email, смена метода публикации, новые зависимости без истории

Крупные компании уже внедряют эти практики в рамках DevSecOps. Малые проекты — пока нет. Именно они и составляют большую часть из 174 000 пострадавших пакетов.

Итог

За 3 часа 30-31 марта 2026 года один скомпрометированный аккаунт мейнтейнера превратил библиотеку с 100 млн загрузок в неделю в вектор доставки RAT на macOS, Windows и Linux. Атака остановилась не потому, что сработала защита большинства команд — а потому что Elastic Security Labs вела поведенческий мониторинг и быстро инициировала удаление пакетов из реестра.

Периметр сети, права доступа, свой код — всё это давно под контролем. Зависимости — чужой код, за которым стоит конкретный человек с учётной записью — оставались вне этого периметра. Инцидент с Axios закрыл этот слепой пятно для тех, кто его заметил.

Те, кто не заметил, узнают позже — когда что-то пойдёт не так.

Подтолкнула к изысканиям меня одна история.

Поскольку я участвую в пресейлах с клиентами, собеседую кандидатов к нам в компанию, да и в целом много общаюсь внутри отрасли, через меня проходит довольно большой поток людей. Поэтому до меня долетает множество разных историй. Одна из них – про новый стартап. Его основатель делает сервис доставки наподобие Яндекса в Казахстане для уже существующей (своей) курьерской службы.

Когда мы говорили с ним в сентябре, планируя расширять штат разработчиков, он не собирался брать тех, кто не использует нейронки для написания кода. С учетом негатива в сторону вайбкодинга, я удивился и обратил внимание на его рассказ.

Через некоторое время мы встретились снова. Он уже активно собеседовал людей и жаловался, что никто в отрасли нормально нейросетями не умеет пользоваться. Рынок еще не переквалифицировался… Но он все еще настаивал на новом подходе к проектированию.

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

Движемся от проектирования

Я понял, что на качество результата работы нейросети очень влияет подход к проектированию. Писать таким образом код – как разговаривать с джуном, который знает синтаксис языка, но не понимает, как писать правильно, как должны работать микросервисы, как они между собой взаимодействуют в проекте, как все это должно запускаться и т.п. Так что я пошел подтягивать навыки проектирования: изучил подходы к написанию ТЗ, углубился в DDD, BDD, SDD, которые и начал применять, чтобы лучше формулировать задания.

Как в итоге выглядит процесс: я беру какой-то концепт, декомпозирую его в соответствии с моделью C4. А потом начинаю взаимодействовать с нейросеткой.

Помните, как мы создавали системы на блокчейне? Спека должна была стоять во главе угла, поскольку любые изменения в уже запущенную систему внести очень дорого. Смарт-контракты, которые живут в продакшене, уже не остановить. Поэтому спека и контракты должны разрабатываться в первую очередь. Сначала мы описываем их на бумаге, потом пишем спецификации и только по ним код и всю архитектуру. Это Spec-Driven Development (SDD).

Обычно в других сферах разработки все сильно проще. Поэтому требованием сначала писать спеки пренебрегают. Но с точки зрения взаимодействия с нейронкой это очень хороший подход. Если его не использовать – не объяснять нейросети, что нужно на выходе получится как в известной формулировке: “Без ясного ТЗ результат ХЗ”. Это та самая история про написанный нейросетью макаронный код, в котором человеку разобраться уже очень сложно.

Чтобы самому не закопаться в документации, задачу написать спеку тоже можно выдать нейросети, указав, какие при этом нужны API, методы и структуры данных. Ее же можно попросить описать юзеркейсы бизнесовым языком, используя Behaviour-Driven Development (BDD). С Domain-Driven Design (DDD) несколько сложнее. Нейронка в этот подход не умеет, но его можно реализовать руками, грубо говоря, на доске со стикерами или в Miro.

Спеками дело не ограничилось. Я пошел копать дальше и в своих изысканиях наткнулся на ролевые истории, когда ты просишь нейросеть встать на позицию, допустим, DevOps или QA-автоматизатора, и покритиковать только что написанные спецификации. Дошел до того, что в параллели запускал четыре-пять ролей, которые критиковали ТЗ, спорили между собой и пытались прийти к консенсусу. В процессе они подсвечивали целый пул проблемных сценариев ТЗ, указывая доступные варианты решения. Мне оставалось только выбрать тот, что я считал правильным, и дополнить ТЗ. Каждый предметный пункт при этом претерпевал до 10 итераций изменений. И только когда они были все внесены, запускалась разработка.

В целом получалось весьма неплохо. А можно было пойти дальше и вспомнить про более жесткие требования к коду – что есть разные модели структуры данных, чистый код или стандарты его написания (например, PEP8 в Python). Нейросеть можно заставить писать все в соответствии с ними, скормив ей текст правил. Причем, человек, который заявляет, что пишет свой код на основе этих стандартов, скорее всего, сделает это хуже. Нейросеть также можно заставить отрефакторить уже написанный код в соответствии с этими стандартами. Она сделает это минут за 15 – щелк и готово – в то время, как человеку придется долго переписывать весь проект, вложив в это огромный труд.

Первые работающие проекты

Буквально за месяц, набив руку на декомпозиции задач, я написал свой первый проект –прототип игрушки в 2D. На голом движке Pygame герой из зеленых, красных и коричневых квадратов бегал по карте, ставил и разбивал кубики.

Второй мой кейс – за новогодние праздники я написал простое управление складом для своих домашних, которые занимаются изготовлением мерча по играм. Бэкенд на Go, фронт на Next JS. Здесь нейросеть сделала все – написала спецификацию, полное ТЗ и тест-кейсы (обеспечила unit, end-to-end тесты и проверку фронтенда с полным прокликиванием всех сценариев). На сладкое я получил 100% покрытие тестами, чего не добивался в реальной жизни ни в одном проекте.

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

Ложка дегтя – квалификация архитектора

Осознав возможную скорость проектирования, я пробовал запустить все в параллель - четыре нейросети сразу писали код. И все получилось! В теории, если написано ТЗ, я мог бы так озадачить любое количество нейросетей. Потом писать следующее ТЗ и снова запускать модель. Так можно даже прикрывать отсутствие у себя каких-то знаний - по бэку, фронту или тестированию.

Например, QA я более-менее понимаю, бэкенд – тоже, SRE и DevOps навыки у меня отличные и с архитектурой тоже хорошо. Однако закрыть полный цикл разработки без нейросети я не мог, потому что у меня слабые скиллы по фронтенду. Нейросеть помогла компенсировать эту “хромоту” за счет тестов.

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

Плата за доступ

В своих экспериментах я использовал облачные модели. За 5 дней работы (примерно по 6 часов) при создании складского инструмента MiniMax M2.1 потребовала около 2 тысяч рублей. Подписка на Claude Sonnet 4.5 – а сейчас это лучшая нейросеть для написания кода – стоила бы дороже, особенно если брать отечественный платежный шлюз. В зависимости от способа оплаты, потребовалось бы от 4 до 10 тысяч рублей.

Не так давно Nvidia анонсировала свои коробочки для запуска моделей – DGX. Выглядит как неттоп, подключается по сети. По сути, это маленький компьютер, в котором очень много быстрой памяти. Его можно использовать, чтобы запускать нейронную сеть локально, грубо говоря, на своем рабочем месте. Вижу, что аналогичные коробочки выпускает Raspberry Pi, Orange Pi и другие. Но пока ничего из этого нет в продаже в РФ (то, что есть, продается по заоблачной цене).

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

Похоже, упомянутые коробочки тоже метят в тренд. Мы подходим к моменту, когда каждому разработчику нужна будет нейросеть на рабочем месте. Вместо видеокарт будем покупать эти отдельные блоки, чтобы нейронка жила на столе, а не в облаке по подписке. И нам придется за это заплатить.

Кстати, заплатить придется не только деньгами, но и навыками. Это же все придется поддерживать!

Хорошо описал ситуацию мой коллега, Михаил Евдокимов: “Модель в ноутбуке у Data Scientist'а – это 0% бизнес-результата. Нужен MLOps, который позволит модели работать в реальном мире, под нагрузкой, 24/7, и не деградировать. Обучить модельку – это не так сложно. Вот у тебя модель готова, высокая точность. Но сделать так, чтобы она работала в инфре, чтобы она работала на новых данных и не теряла качество – вот это задача. Внедрить ее так, чтобы люди реально пользовались, чтобы данные корректно подтягивались с 1С-ки и других разных источников, нормально обрабатывались, чтобы ничего не ломалось. Сотрудник случайно вобьет что-то не так в 1С, данные с этой ошибкой подтянутся в модель – произойдет сбой, модель нормально не обучится или выдаст ерунду. А потом модель еще дообучать нужно (потому что мир меняется, жизнь меняется, тренды меняются). А еще модель может начать деградировать со временем.  Всё это сделать и заставить работать стабильно – это и есть самая большая задача на самом деле”.

Что в итоге

Большинство пользуется нейронками как продолжением гугла. Но отрасль разработки меняется прямо на наших глазах – мы в начале этой волны. Думаю, что очень скоро нейросети станут стандартом де-факто и одним из требований к разработчикам в вакансиях.

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

Сеньоры-мидлы-джуны

У Git in Sky очень широкая вилка в плане найма, т.е. мы берем и джунов, и мидлов, и сениоров. На какую роль подойдет человек, становится понятно еще на этапе собеседования. Я сразу стараюсь оценить и уровень, и проект, куда человек хорошо впишется.

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

Джунов также растим, но несколько иначе. В принципе джуны в моем понимании — это не самый низкий уровень. Первый — это интерны. Грубо говоря, студенты, которые уже что-то видели и хотят в джуны. Мы же говорим о следующем уровне, до которого надо еще дойти.

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

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

Каких джунов мы ищем

Общаясь с потенциальным коллегой, я всегда смотрю не столько на технические знания, сколько на софт скиллы и способность принять нашу культуру. Важна готовность решать проблемы и правильный подход к ним. А еще базовое знание Linux (можно даже без остальных инструментов DevOps).

Желание справляться с трудностями

Мне нравятся люди, которые еще на этапе собеседования высказывают готовность решать проблемы. Особенность нашей работы такова, что на проекте придется чаще всего оставаться с этими проблемами один на один. Готов ли человек к этому?

На мой взгляд, если джун придет и скажет: “У меня не получилось”, то получит удивленный взгляд. Если ты джун, изучи проблему, собери кейсы, построй теорию (а может и не одну) и с этим уже иди к старшим коллегам, чтобы узнать, куда копать дальше. Это шанс продемонстрировать активность в решении проблемы. И если человек делает так, ему хочется помочь. Мы любим именно таких джунов — они быстро растут и развиваются.

На собеседованиях я рассказываю реальные кейсы с проектов: такой-то стек под капотом, приходит разработчик и надо разобраться, почему у него не хватает какой-то переменной на проде. Это придется гуглить и решать, скорее всего самому. Вопрос в том, готов ли человек к этому? Будет ли он ковыряться до победного? Идеальный вариант, если человек сам уверен — уже сталкивался с чем-то подобным и вывез, а значит и тут найдет решение.

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

Готовность к переработкам

Да, говорят, что переработки — это плохо — ненормированный график, нарушение баланса работы и личной жизни и т.п. Но это лишь часть картины. Зато мы можем себе позволить работать всего несколько часов в день, используя в том числе и рабочее время для выполнения каких-то личных дел. Например, могу сходить в МФЦ в обед. Если в этот момент не было инцидента, никаких вопросов.

Умение диагностировать проблемы

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

В последнее время на рынке труда много специалистов после курсов DevOps. Но на 99% все курсы, которые сейчас есть в интернете, построены вокруг изучения только лишь базовых инструментов — как собирать Docker или настраивать CI/CD. Там не дают фундаментальных знаний о том, как, допустим, дебажить проблемы в ОС Linux (вероятно, курсы предполагают, что эти знания у кандидатов уже есть).

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

Сисадмины, эникейщики в половине или даже большей части случаев обладают нужными навыками. Все зависит от того, что именно они админили. Мне очень нравятся ребята из техподдержки операторов домашнего интернета или хостинг-провайдеров. Они все в принципе умеют работать в консоли, знают сети и подходы к поиску проблем. Каждый день 99% своего времени они как раз этим и занимаются.

Путь обучения

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

Что это за инструменты:

• бекапы

• мониторинг

• логирование

• аллерты

• disaster recovery

• CI/CD

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

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

Залог успеха этого процесса — правильный руководитель и грамотная организация команд.

Навыки руководителя

Чтобы не провалить образовательный процесс, руководителю тоже нужно обладать определенным набором навыков. Не каждый тимлид может справиться с джуном.

Как правило, самое главное препятствие — это неумение ставить цели. Постановка цели по SMART (Specific — конкретная; Measurable — измеримая; Achievable — достижимая; Relevant — значимая; Time bound — ограниченная во времени) — вроде бы элементарная везде распиаренная штука, но многие не умеют ей пользоваться — не обозначают конечный результат, когда распределяют задачи.

Например, я прошу мидла сделать задачку уровня тимлида — расписать решение проблемы. Он пишет: “Сделать то-то, сделать то-то”. Все здорово, но как я принесу это бизнесу? В чем для него ценность? После обсуждения выясняется, что в результате выполнения всех пунктов будет работать метрика, указывающая, что сервис сбоит. И это действительно ценность — вот, что надо было писать с самого начала. Но перевернуть мышление в эту парадигму, научить технаря говорить на языке результатов, что по сути равно языку бизнес менеджеров, очень сложно. Так что тимлиды, которые умеют с джунами говорить на техническом языке, а с бизнесом — на бизнесовом, которые умеют декомпозировать сложные задачи на простые шаги и понимают, кто из ребят сможет с ними справиться, — на вес золота.

Есть четыре уровня делегирования:

• Первый — когда человек готов работать только по подробной инструкции. Если подобный подход выявляется на собеседовании или испытательном сроке, мы расстаемся с таким человеком. Увы, такие джуны быстро не вырастут. А еще хуже, когда такие качества проявляются у руководителя.

• Второй — когда он может работать по частично доступной информации (додумать или найти источник информации, где то в конфигурации, у команды разработки, недостающие участки и просто погуглить и решить задачу).

• Третий — когда можно сообщить о проблемном месте, а он может сам найти источник проблемы, сформулировать способы решения. По сути это снова про навыки диагностики проблем. Это кунг-фу необходимо тимлиду.

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

Здесь я вспомнил об этих уровнях скорее в контексте руководителей. Для работы с джунами (да и в целом для работы в нашей компании) нужно быть хотя бы на третьем. Только так можно вычленять из общего потока кандидатов джунов с навыками диагностики проблем и нагружать их соответствующими задачами.

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

Организация команд

Тандемы

В нашей компании хорошо себя показала практика микрокоманд — мы собираем тандемы из двух коллег, которые занимаются определенным набором проектов.

Идею тандемов я подсмотрел очень давно — еще в начале нулевых — в какой-то книжке.  Забавно, что знания из той книги пригодились спустя столько времени. Позже я столкнулся с этими идеями в книге по менеджменту “Это так не работает”. Там это называлось “микрокоманды”. Была высказана мысль, что даже если у тебя есть команда из условно 10 человек, в ней все равно лучше выделить микрокоманды, и они будут работать эффективнее. Либо так или иначе они образуются сами.

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

На собеседовании я смотрю на специалиста и сразу стараюсь понять, кто мог бы быть у него в паре. Т.е. это речь не столько о “подойдет по стеку или нет” (понятно, что человек должен пройти по хардам для текущего проекта), сколько о комплексном видении и хард, и софт скиллов. Причем, я не обязательно подбираю джуна под сениора или ищу, чтобы сениор больше общался с клиентом, показывая пример джуну. Вполне возможна ситуация, когда за счет прокачанных софт скиллов джун, слабый в техничке, и с клиентом договорится, и к коллегам сходит, чтобы ему подсказали грамотное решение. Суть именно в комплексном взгляде. Важно, чтобы тандем — эдакий паззл внутри коллектива — собрался и заработал.

В зависимости от ситуации мы ищем на собеседованиях разное. Иногда нужны руки, которые будут выполнять задачи. А иногда, наоборот, “говорящая голова”, которая должна грамотно общаться с клиентом, чтобы я мог отпустить ситуацию и немного разгрузиться.

Самостоятельность во главе угла

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

Тут важна инициативность в деталях, вплоть до того, что коллегам стоит понимать, как планировать ночные работы и согласовывать их с клиентом (даже если коллеги — чистые технари). Если у клиента принято просто написать в Telegram — это один разговор. Если же надо обязательно подготовить обращение к ответственному лицу и собрать аппрувы — другой. Надо пройти правильным путем, и главное, чтобы я не контролировал эти процессы.

Чтобы был шанс отпустить ситуацию, я объясняю, как сделать правильно, и фигурально выражаясь, “отворачиваюсь”. Если в итоге я вижу, что задача выполнена — хорошо. Моя цель, как тимлида, достигнута. Но так происходит не всегда, чаще инженер совершает ошибки так или иначе. Главный секрет при постановке задачи всегда объяснять преследуемые цели и критерии “когда мы считаем что задача готова, что должно быть готово” используя метод SMART .

Если ошибки случаются, я не жду какого-либо специального one-to-one, а прихожу сразу. Например, мы что-то обсуждаем с клиентом в созвоне и я даю слово инженеру, который делал задачу. А инженер говорит на встрече какие-то глупости. Прямо в процессе коммуникации я, как фасилитатор созвона, могу дать ему отсечку — самостоятельно рассказать, что он сделал более бизнесовым языком. После этого прихожу уже в личку, где мы с инженером разбираем ситуацию — почему я его прервал, какие вещи нельзя говорить клиенту и т.п. Короче, проводим работу над ошибками. Объясняю, как говорить с клиентом в сложных ситуациях, как работать с возражениями, как быть с плановыми работами, как ставить задачи, формировать цели и критерии приемки по SMART.

В целом у нас в коллективе довольно простая атмосфера. На это во многом влияет личная харизма, и я стараюсь это поддерживать. Младшие всегда могут прийти к старшим, да и я выступаю эдаким играющим тренером и равными правами по отношению к остальным участникам коллектива. Мотивировать всех участников к инициативе. Т.е. нет проблем с тем, чтобы сократить количество грабель, на которые наступать. И со временем количество ошибок действительно уменьшается В среднем инженеры уходят в эдакое “самостоятельное плавание” примерно через 4-8 месяцев после начала работы. С этого момента их уже можно почти не контролировать, лишь иногда задавать правильные вопросы. Например, инженер приносит мне план разобрать старый кластер баз данных у клиента. А я спрашиваю, а где план отката и когда ты будешь делать бекапы? Если это не было заложено изначально, инженер идет и переделывает план. Так последовательными итерациями мы приходим к полностью самостоятельному решению.

Джуны всем нужны

Опыт показывает, что джуны — это не так страшно, если уметь их правильно отбирать и готовить. При нормально построенном наставничестве джун до сениора может вырасти за 5 лет. Google считает, что на этот процесс уходит чуть больше — порядка 6-8 лет (корпорация привязывается к циклу жизни продукта и считает, что специалист до уровня сениор должен прожить весь этот цикл в одной или нескольких компаниях).

Но сути эта разница в оценках не меняет. Срок не такой уж и большой, если правильно направить усилия. Успешная работа с джунами — это не так страшно. Довольно быстро вы заметите, что из слабого звена команды джуны прекращаются в уверенных и квалифицированных коллег.

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

Подумал, как же отучить от такого. Сходил в большой садоводческий магазин и купил 2 драцены. Принес в офис, поставил и подписал стикеры «джун Федя» и «джун Витя».

Сказал своим джунам: «Если ты будешь называться джуном, поставлю тебя в горшок рядом и буду поливать водичкой».

P. S. Ни одна драцена и ни один джун не пострадали.

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

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

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

“Подъем по тревоге” ночью или в выходные происходит не часто (один-два раза в месяц). Только если отваливается проект, по которому ответственный я, или кто-то из инженеров моей группы, который не смог принять вызов.

Как и у многих хостинговых компаний на рынке, у нас сложилась “многоярусная” система реагирования на проблемы с инфраструктурой. Первый уровень - это младшие дежурные, которые сидят посменно: по 12 часов в режиме 24/7. Когда-то и я начинал с такого, но в другой компании.

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

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

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

10:00. Утренний скрам

Штатный подъем — тремя часами позже. Умываюсь и иду на дейлик в 10:00 по Москве, где мы отчитываемся о наших задачах. Как правило, по задачам у нас две встречи: ровно в десять мы отчитываемся, что делали вчера — в данном случае в пятницу, что произошло за выходные, что будем делать сегодня и в какой последовательности.

Эта встреча помогает правильно расставить приоритеты. Обязательно присутствуют проджекты, которые приносят обратную связь от заказчиков - допустим, клиент приходил в пятницу и просил побыстрее что-то сделать. Мы оцениваем срочность и, если это необходимо, раздвигаем очередь задач, чтобы сфокусироваться на самом важном.

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

10:20. Разбор полетов

Следом проходит After scrum, где мы уже устраиваем разбор полетов. Тема сегодняшнего утра - почему подъем по тревоге был у меня, а не у ответственного инженера. Как выяснилось, тот поставил телефон на зарядку в соседней комнате и не услышал звонка. Обсудили ситуацию, договорились больше так не делать.

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

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

Чаще всего, кстати, при приемке срабатывает проверка “на дурака” - что в задаче действительно выполнены все пункты, именно так, как просил клиент, а не как додумал DevOps-инженер. В анализе задач всегда приходится включать здравый смысл. В нашей сфере задача вполне может быть решена (допустим, попросили добавить какой-то флаг PHP — ты добавил), а проблема клиента — нет. Это частая история. Иногда даже приходится применять решение, противоречащее best practice, потому что именно оно, а не что-то другое, решает задачу клиента.

11:00. Архитектурный созвон

Расходимся мы около 11 часов. После этого по понедельникам я созваниваюсь с архитекторами — это 3-4 человека по всей команде. Зачастую присутствуют и проджекты, которые ведут данные проекты.

У нас около 30 проектов — больше, чем у других команд в компании. На созвоне проджекты называют их по алфавиту, а мы обсуждаем, что в них произошло за последнюю неделю. У кого-то не происходило ничего, где-то мы отчитались о последних выполненных работах, но клиент с обратной связью не вернулся, у кого-то были инциденты, и мы их починили, и так далее. Событий много, так что и времени на эти обсуждения уходит прилично — до полутора часов.

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

12:30. Анализ логов

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

Скорее всего роль сыграли изменения от разработки клиента. Моя задача: описать случившееся и отчитаться об общем даунтайме, если он был. Сегодня инцидент имел место, но система просто перешла в режим деградации, на продукте это никак не сказалось. Готовый отчет я направляю разработчику, который ведет проект со стороны клиента, а также прикладываю к задаче в нашем таск-трекере (в зависимости от того, каким инструментом пользуется клиент).

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

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

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

14:00. Ворох задач

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

Помимо встреч, мне с разных сторон прилетают задачки. Например, приходят коллеги из отдела маркетинга с заявками от клиентов. Они ждут совета, как и в какой пакет обернуть требуемую услугу, какую сделать презентацию. Будучи архитектором, я также занимаюсь планированием различных работ и разбором уже выполненных операций перед тем, как они будут сданы клиенту. А еще с каждым из клиентов у меня есть еженедельный созвон по событиям за эту неделю. Могу так же, как инженер, сделать какие-то задачи из общего трекера: сегодня я переделал раннеры в GitLab CI, достал данные из логов по просьбе коллеги, ответил на вопросы в чате разработчиков.

В своей работе мы в основном опираемся на подход инфраструктура как код (Iaac). Основные инструменты — Ansible и Terraform, так что 80% времени мы работаем с заготовками Ansible. У нас есть копилка плейбуков для Ansible, которые модифицируются всеми командами. Это общий котел с заготовками, откуда мы периодически вынимаем и добавляем нужное. Но вопросы в чате все равно возникают часто.

Иногда дело доходит и до собеседований. Как именно я собеседую — на что и почему смотрю — я расскажу отдельно. Это довольно обширная тема.

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

19:00. Вечер трудного дня

Мой рабочий день заканчивается в 19 часов. Под конец дня я заполняю отчет, куда потратил свое время - мы трекаем все в Redmine. После этого иду к техдиру и спрашиваю в переписке, как прошел день, какие есть проблемы, не нужно ли что-то подхватить. Делаю я это уже обычно с телефона, сидя на кухне. С техдиром мы в свободной форме обсуждаем ситуацию и расходимся отдыхать.

Кажется, что мой график не нормирован. Но на самом деле это только одна сторона медали. Вторая сторона, что я могу работать всего 4 часа за день. У нас свободное отношение к присутствию на рабочем месте (если не случился инцидент, конечно). Надо жену в магазин отвезти посреди дня — пожалуйста. В МФЦ документы подать — тоже без проблем.

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

Вне дома я люблю слушать аудиокниги. В последнее время мне нравится "боярка". Порой книги настолько увлекают, что я даже пытаюсь растянуть дорогу на машине, чтобы послушать подольше. Сейчас слушаю “Идеальный мир для лекаря”.

Вечером, уже дома, могу посмотреть кино с женой или сажусь за свой пет-проект. Просто изучать технологии мне уже не так неинтересно, а под конкретную задачу — вполне. В рамках пет-проекта я собираю опенсорсный сервис мониторинга — эдакий “швейцарский нож” девопсов. Пытаюсь найти для него кирпичики: смотрю чужие проекты и сервисы, экспериментирую с ними. Там бывают интересные задачки — можно случайно залипнуть и “очнуться” в 3 часа ночи, понимая, что уже как 3 часа ты должен спать =D.

День подошел к концу. Завтра снова буду следить за инфраструктурой и чинить возникающие поломки, чтобы сделать разработчиков наших клиентов чуть более счастливыми.

Хочу запросить обратную связь у коллег-айтишников. Что интересного у вас в течение дня происходит?