Наблюдаемость
Структурное логирование: построй production-pipeline логирования
Читать про структурное логирование — не то же самое, что поднять pipeline, переживающий и аудит, и инцидент. Построй небольшой сервис, дай ему реальную схему лога, маршрутизируй log level, засемплируй объём, отредактируй PII, скоррелируй по trace_id и вынеси audit-лог — а потом докажи каждое свойство запросом или тестом, а не утверждением.
Преврати юнит в рабочий pipeline: эмить OTel-форму JSON в stdout, дай коллектору заняться sampling, редакцией и маршрутизацией, и продемонстрируй, что операционные и audit-логи попадают куда надо с правильными retention, immutability, доступом и trace-корреляцией.
Возьми небольшой HTTP-сервис (Node/Go/JVM/Python) и построй production-grade pipeline структурного логирования end-to-end: OTel-схема, маршрутизация по log level, sampling на уровне коллектора, двухслойная редакция PII, автоматическая корреляция по trace_id и выделенная подсистема audit-логов — доказывая каждое свойство запросом, тестом или измерением до/после.
- Снятая лог-строка с каждого эндпоинта, показывающая полную OTel-схему, правильный log level и ненулевой trace_id — включая строку async-пути, несущую входящий trace_id.
- Таблица объёма до/после, доказывающая, что success-path sampling срезал INFO на ~90%, тогда как запрос подтверждает выживание 100% WARN/ERROR.
- Доказательство, что чувствительный эндпоинт не утекает PII: запрос по индексированным логам на тестовый email/пароль/токен возвращает ноль попаданий, и редакция держится, даже когда тест намеренно дампит весь body запроса на ошибке.
- Тест CWE-117 проходит: комментарий с поддельным переводом строки порождает ровно одну лог-запись, а не две.
- Audit-событие приземляется в audit-индекс (не в операционный), и запрос показывает, что политика retention/доступа операционного индекса отличается от audit-индекса.
- Абзац разбора: какой слой что поймал (deny-list у источника против скраббера коллектора), почему sampling учитывает severity и что ломается, если audit и операционные логи делят один индекс.
- Добавь панель и алерт здоровья trace_id: считай долю строк с trace_id из всех нулей по сервису и алерти выше 1%, затем намеренно сломай async-путь, чтобы увидеть срабатывание.
- Добавь retention tiering: горячий (7-15д, полностью индексирован), тёплый (30-90д, только scan), холодный (S3 ~$0.023/ГБ-мес) и покажи запрос по старому инциденту, идущий по тёплому слою.
- Добавь pattern-based sampling, схлопывающий болтливый дубликатный шаблон лога на коллекторе при сохранении редких паттернов на 100%, и измерь дополнительный срез объёма.
- Сделай audit-лог tamper-evident: хеш-цепочка или подпись каждой audit-записи и верификатор, детектирующий единственную изменённую запись.
Это pipeline, который ты поднимаешь для каждого реального сервиса: эмить OTel-форму JSON в stdout, классифицируй log level так, чтобы маршрутизация следовала контракту, автоинжекти trace_id и переживай async-границы, редактируй PII у источника и снова на коллекторе, предотвращай log injection структурно передачей ввода типизированными полями, семплируй на коллекторе сохраняя все WARN/ERROR и вынеси audit-лог в свой pipeline с правильными retention, immutability и доступом. Сделав это однажды на игрушечном сервисе — с запросом или тестом на каждое свойство — ты превращаешь production-версию в мышечную память, готовую к аудиту.