Опубликовано: 02.10.2026 | Источник: CNews (новости)

Сопровождение производственных ИТ-систем в дипломе: от runbook до SLA-отчётности

Введение: почему кейс «Рикитлаб» — это готовый каркас ВКР

26 марта 2026 года ИТ-компания «Рикитлаб» объявила о запуске комплексной модели сопровождения производственных ИТ-систем — от мониторинга и инцидент-менеджмента до планово-предупредительных работ и SLA-отчётности перед заказчиком. Для выпускника это не просто новость, а легальный способ обосновать актуальность дипломного проекта без воды про «цифровизацию всего». Согласитесь: когда на защите вы говорите «рынок услуг сопровождения формируется прямо сейчас, вот публичный кейс от вендора от 2026 года», комиссия кивает — а не листает телефон.

Ниже — как превратить этот тренд в защищаемую ВКР: какие темы брать, какие метрики считать, какие схемы чертить и где чаще всего валятся студенты. Если вы решаете, как написать ВКР по DevOps/SRE и не хотите скатываться в «ещё один сервис на Flask», — читайте внимательно.

Основная часть: 4 темы, метрики, схемы и код

Тема 1. Проектирование системы мониторинга производственного контура

Актуальность. Кейс «Рикитлаб» прямо говорит: сопровождение = непрерывное наблюдение. Значит, в Главе 1 вы анализируете подходы observability (метрики, логи, трейсы), в Главе 2 проектируете сборщик телеметрии, в Главе 3 валидируете на нагрузочном стенде.

Цель: снизить время обнаружения инцидента (MTTD) на изолированном стенде.

Задачи:

• сравнить OpenTelemetry, Prometheus, Zabbix по критериям ISO/IEC 25010 (производительность, надёжность, сопровождаемость);
• спроектировать архитектуру сбора телеметрии (диаграмма C4 — уровень Container);
• реализовать экспортёры и дашборды;
• измерить MTTD до/после внедрения на 3 сценариях отказа.

Тема 2. Автоматизация runbook-ов и реагирование на инциденты

Тут вы строите pipeline «алерт → автодействие → постинцидент-отчёт». Отличный мостик между теорией (ITIL 4, практики incident & problem management) и практикой. Метрики: MTTR, MTBF, доля автоустранённых инцидентов.

Тема 3. Модель SLA-отчётности для заказчика сопровождения

Кейс «Рикитлаб» включает отчётность перед заказчиком. Значит, в ВКР можно формализовать SLI/SLO/SLA-каскад и построить автоматический отчёт. Это редкая тема — и потому выигрышная: конкурентов на защите почти нет.

Тема 4. Отказоустойчивость и планово-предупредительные работы

Здесь уместны Kubernetes, chaos-инжиниринг и сценарии «что если упадёт узел». Глава 3 — серия экспериментов с фиксацией восстановления.

Что чертить: 4 обязательные схемы

1. C4 Container — компоненты сбора и хранения телеметрии.
2. BPMN-диаграмма — процесс обработки инцидента от алерта до закрытия.
3. UML Sequence — взаимодействие агента, коллектора и хранилища метрик.
4. Схема SLA-каскада — от SLI к отчёту заказчику.

Все схемы оформляйте по ГОСТ 19.701 (ЕСПД) для блок-схем и по правилам оформления UML — единый стиль, подписи, нумерация.

Кусок кода, который украсит Главу 2

Пример конфигурации приёма метрик через OpenTelemetry Collector — можно привести как фрагмент в приложении:

receivers:
  otlp:
    protocols:
      grpc:
      http:
processors:
  batch:
    timeout: 5s
  attributes/cleanup:
    actions:
      - key: host.name
        action: delete
exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
  loki:
    endpoint: "http://loki:3100/loki/api/v1/push"
service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch, attributes/cleanup]
      exporters: [prometheus]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [loki]

Такой фрагмент легко защитить: он показывает, что вы понимаете разницу между receiver/processor/exporter, а не просто копируете docker-compose из статьи.

FAQ: что реально спрашивают студенты

Источник: «Рикитлаб» запустила комплексную модель сопровождения производственных ИТ-систем (опубликовано 2026-03-26)