Что такое доке: полевой справочник

Первый шаг — зафиксировать канал и роль собеседника. В Slack-канале #infra с высокой вероятностью речь о Docker. В трекере задач типа «Подготовить доке к релизу» — о документе (релизные заметки, чек-лист, спецификацию). В тикете сервис-деска «доке не видит монитор» — о док-станции. Не полагайся на интуицию: открой историю переписки за последние 10 сообщений и ищи ключевые слова: image, container, compose — контейнеры; pdf, docx, sign, approve — документы; thunderbolt, usb-c, power delivery — железо.

Второй шаг — проанализировать глаголы и существительные-спутники. «Образ», «контейнер», «реестр», «сеть», «том» — лексика Docker. «Версия», «черновик», «утверждение», «хранилище», «метаданные» — документ. «Порт», «кабель», «блок питания», «видеовыход» — док-станция. Составь мини-словарь на 5–7 маркеров для своей команды и держи его в закреплённом сообщении.

Когда контекст смешан (например, DevOps просит «обновить доке перед деплоем» — это может быть и образ контейнера, и конфигурационный файл), используй технику «двоякого ответа»: «Подтверждаю: под «доке» ты имеешь в виду Docker-образ сервиса X или конфиг deployment.yaml? Готов оба варианта». Это снимает блокировку и показывает, что ты контролируешь область неопределённости.

Если собеседник не отвечает в течение рабочего тайм-аута (обычно 5–15 минут в синхронном чате), действуй по приоритету безопасности: для инфраструктуры — подними актуальный образ из реестра с тегом latest или по комиту; для документов — выложи последнюю утверждённую версию из хранилища; для железа — проверь физическое подключение и питание. Зафиксируй принятое решение в тикете с пометкой «предположение: Docker/документ/док-станция».

Метод контекстного распознавания работает, пока команда использует более-менее стабильный сленг. При роте сотрудников, смене инструментов (например, переход с Docker на Podman или containerd) или внедрении нового термина «доке» для внутреннего сервиса алгоритм даёт сбой. Опасный признак — когда один и тот же человек в одном дне использует «доке» для контейнера и для документа. Тогда нужен жёсткий словарь проекта: заводишь страницу в вики, вешаешь ссылку в онбординг, требуешь единообразия в код-ревью и PR-описаниях.

Техническое ограничение: если «доке» — это опечатка в автоматизированном скрипте (например, переменная DOCKER_IMAGE записана как DOKE_IMAGE), контекстный анализ не поможет. Нужен статический анализ кода и поиск по репозиторию. Организационное ограничение: в регулируемых средах (банки, госсектор) недопустимо действовать по предположению — требуется официальное уточнение через процесс управления изменениями.

После выполнения действия нужно подтвердить, что достигнут именно нужный результат. Для Docker: контейнер в статусе healthy, порты слушаются, эндпоинт отдаёт 200 OK. Для документа: статус «Утверждён» в системе управления документами, есть подпись ответственного, версия зафиксирована в истории. Для док-станции: внешний монитор определён системой, зарядка ноутбука идёт (индикатор питания), периферия работает. Никакое «вроде заработало» не считается — только наблюдаемые признаки.

Если результат не совпадает с ожиданием, вернись к диагностике: возможно, «доке» означало третий вариант (например, внутренний микросервис с кодовым именем «Doke»). В таком случае инициируй встречу «триаж терминов» на 15 минут с заинтересованными сторонами и зафиксируй итог в словаре проекта.

Чтобы исключить повторные неопределённости, заведи единый словарь терминов-омографов. Формат: термин, варианты написания, каноническое значение, ответственный за актуализацию. Пример строки: «доке — [docker, доуке, доуки] — Docker-образ/контейнер — @devops-lead». Размести словарь в README репозитория, в вики, закрепи в общем чате. Введи правило: любое новое сокращение, короче 4 символов, проходит ревью в PR к документации. Это стоит 5 минут на внедрение и экономит часы уточнений в месяц.

Автоматизируй контроль: добавь в pre-commit хук проверку на наличие «доке» в коде и коммитах (regex: \\bdoke\\b) с предупреждением «Используй полное название: docker / document / dock». В CI добавь джоб, который ищет этот токен в артефактах и падает с подсказкой. Так термин либо уйдёт в официальный словарь, либо исчезнет из кодовой базы.

В старых репозиториях и скриптах «доке» может встречаться как имя переменной, хоста, сервиса. Массовый рефакторинг рискованен: может сломаться неочевидная зависимость. Стратегия: 1) аудит — grep -r doke . --exclude-dir=.git; 2) классификация каждого вхождения (опечатка / кодовое имя / локальный сленг); 3) поэтапная замена с прогоном тестов на каждом этапе. Для кодовых имён (например, сервис «doke-api») оставь как есть, но добавь в словарь с пометкой «legacy, не переименовывать».

Если «доке» — это название внутреннего инструмента, которое команда использует годами, не заставляй их переучиваться. Зафиксируй в словаре: «doke — внутренний CLI для деплоя (legacy), см. doke --help». Главное — устранить коллизию с Docker и документами в текущей коммуникации. Новые инструменты называй однозначно: deploy-cli, doc-gen, dock-mgr.

Ключевой вывод: «доке» — это маркер неопределённости, а не термин. Твоя задача — не угадать, а снять неопределённость за фиксированное время. Внедри словарь проекта, автоматизируй поиск коллизий в коде, учи команду протоколу уточняющего вопроса. Так «доке» перестанет быть источником инцидентов и станет триггером качественной коммуникации.