Мне был нужен инструмент, который позволил бы описать наши сервера, описать какие приложения на них запущены, как всё это связано между собой, как делаются бэкапы баз данных и так далее. Если бы я был DevOps, то наверное написал бы для этого Terraform конфиг. Но я архитектор, поэтому визуальные схемы мне ближе. В итоге мы скрестили ежа с ужом (ArchiMate с AWS Cloud Notation) — если вам интересно что получилось или вам интересно как в принципе создаются новые языки моделирования, то добро пожаловать в статью.

Пример модели ИТ-инфраструктуры

Итоговая схема выглядит следующим образом:

У нас два сервера: основной и бэкап. На основном сервере 4 ядра, 8 ГиБ памяти, 80 ГиБ жёсткий диск. Причём эти параметры — это не просто надпись на картинке, они хранятся в структурированном виде:

Мы учли, что на сервере может быть также GPU, NPU, ... При изменении этих параметров автоматически меняются значок и подпись на диаграмме. Также уделили внимание единицам изменения — 8 гигабайт и 8 гибибайт всё‑таки существенно отличаются.

Из схемы видно, что само приложение у нас запущено в Docker и состоит из нескольких контейнеров:

• Nginx, который отдаёт фронтенд и перенаправляет запросы в API Gateway

• API Gateway, который проверяет JWT‑токены в Keycloak и сохраняет пользовательские сессии в Redis, чтобы пользователей не разлогинивало после перезапуска приложения

• Бэкенд с базой данных

• Keycloak с базой данных

• Nginx с лендингом нашего приложения

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

Всё это спрятано за системным Nginx, основная задача которого — это поддержка HTTPS. SSL‑сертификат мы создаём с помощью Let's Encrypt. Два раза в сутки запускается certbot, который проверяет сколько времени осталось до истечения сертификата. Если меньше 30 дней или сертификат отозван, то создаётся новый. На мой взгляд очень круто, что в модели можно описать даже такие детали, чтобы они не оставались в голове человека, который всё это настраивал.

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

Наконец, описана доменная зона с DNS‑записями.

Лично мне очень нравится эта схема. Она позволяет любому новому человеку на проекте сразу понять как у нас всё настроено.

Картинка конечно красивая, но что с ней делать?

На неё можно не только смотреть, но и скачать в виде JSON или XMI. Можно обновлять эту модель через REST API или Model Context Protocol.

Приведу небольшой фрагмент модели:

{
  "json": { "version": "1.0", "encoding": "utf-8" },
  "ns": { "itit": "https://architeezy.com/metamodel/itit/1.0.0/itit" },
  "content": [
    {
      "id": "019ba7e9-5540-7cae-a90f-97693f279342",
      "eClass": "itit:InfrastructureTopology",
      "data": {
        "name": "IT Infrastructure",
        "folders": [
          {
            "id": "019ba869-13c3-70df-8c0a-5319d784db2d",
            "eClass": "itit:Folder",
            "data": {
              "name": "Main Server",
              "folders": [
                {
                  "id": "019ba86b-6206-7ea3-bb9e-1cf6b0240cdf",
                  "eClass": "itit:Folder",
                  "data": {
                    "name": "Hardware",
                    "concepts": [
                      {
                        "id": "019ba814-660f-7999-988f-6e123aef47ae",
                        "eClass": "itit:VirtualMachine",
                        "data": { "name": "Main Server" }
                      },
                      {
                        "id": "019ba816-b1cb-7f6d-befd-1453477b0246",
                        "eClass": "itit:ProcessingUnit",
                        "data": {
                          "count": 4.0,
                          "memorySize": 8.0,
                          "memorySizeUnit": "Gibibyte"
                        }
                      },                      

Существенное отличие от AWS диаграмм, нарисованных в draw.io в том, что это не картинка, а данные. По этому JSON можно генерить конфиги. Можно его редактировать в виде такого дерева:

В будущем добавим ещё табличный и текстовый редакторы.

Нотация моделирования ИТ-инфраструктуры

Как всё это сделано? Чтобы создать новый язык моделирования первое что вам нужно — это метамодель, описывающая структуру ваших моделей (ниже будут более крупные фрагменты):

Базовые объекты:

Infrastructure Topology — это корневой элемент модели. Модель может содержать папки (Folder). В них содержатся понятия (Infrastructure Concept) и диаграммы (Diagram). Понятия бывают двух видов: элемент (Infrastructure Element) или отношение (Infrastructure Relationship).

Вообще не очень правильно смешивать модели и диаграммы, они должны храниться отдельно. Например, для BPMN есть отдельная метамодель BPMN DI (Diagram Interchange). Для UML есть так же UML DI. Но проблема в том, что если сами модели BPMN и UML в разных инструментах моделирования ещё относительно совместимы — вы можете создать UML модель в одном инструменте, выгрузить её в XMI формате и загрузить в другой инструмент. То диаграммы обычно гораздо сложнее переносить между разными инструментами моделирования. Поэтому мы решили не усложнять жизнь и пошли путём ArchiMate — создали одну метамодель для моделей и диаграмм.

Инфраструктурные элементы могут быть следующих типов (далее рассмотрим каждый более подробно):

• Бизнес‑элемент

• Расположение

• Сетевой элемент

• Вычислительный элемент

• Платформенный элемент

• Приложение

• Конфигурационный элемент

• Группирующий элемент

Бизнес-элементы

Элементы, которые физически никак не представлены в ИТ‑инфраструктуре:

На диаграмме они изображаются следующим образом:

Расположение

Элементы, описывающие где физически расположены серверы:

На диаграмме они изображаются следующим образом:

Сетевые элементы

Сети, подсети, IP‑адреса и так далее:

У этих объектов уже есть дополнительные атрибуты, а не только название.

На диаграмме они изображаются следующим образом:

Вычислительные элементы

Это физическое или виртуальное железо на котором всё работает:

На диаграмме они изображаются следующим образом:

Платформенные элементы

Возможно не самое удачное название, но тем не менее:

На диаграмме они изображаются следующим образом:

Приложения

Самая разнообразная категория элементов:

Мы используем разные цвета для основных элементов, вспомогательных элементов и для хранилищ данных:

Сервис — это приложение, которое запущено постоянно. Задача — это, например, скрипт который запускается по cron. Провайдер идентификации — это, например, Keycloak. Мы стараемся максимально абстрагироваться от конкретных технологий, чтобы модели были относительно устойчивыми к изменению технологического стека.

Конфигурационные элементы

Конфиги, переменные окружения и так далее:

На диаграмме более критические элементы показываем красным цветом:

Группирующие элементы

Такая себе история делать класс с единственным подклассом:

Группа ресурсов — это, например, один docker‑compose.yml файл.

Для всех типов объектов (не только для групп ресурсов) можно показывать связи либо линиями на диаграмме, либо вложенностью. Мы подсмотрели эту идею в ArchiMate и мне она очень нравится:

Отношения

Типы отношений мы в значительной степени заимствовали из ArchiMate:

На диаграмме они изображаются следующим образом:

Честно говоря это самая мутная часть нотации. В ArchiMate не всегда понятно какой тип связи правильнее выбрать. Мы наследуем эту проблему. В будущем добавим ограничения на то какими типами связей какие объекты можно соединять.

Диаграммы

Метамодель для диаграмм:

Диаграммы состоят из фигур и связей. Фигуры могут быть вложенными.

Фигуры могут изображать инфраструктурные элементы. А могут быть просто комментариями или группирующими рамками.

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

Заключение

Что вы думаете об этой нотации? На сколько она полезна?

Вообще, на мой взгляд, для DevOps скорее бесполезна, потому что им безусловно удобнее использовать YAML‑конфиги. Но представьте, что этой схемой пользуются не только DevOps, но и архитекторы, аналитики, разработчики, менеджмент, безопасники, юристы. Безусловно эту модель можно дополнить информацией о рисках, угрозах, лицензиях, информацией об ответственных за каждый сервис.

Можно сгенерировать схему ИТ‑инфраструктуры из архитектурных моделей. Представьте, что вы спроектировали приложение и получаете готовую инфраструктуру без необходимости настраивать Nginx, Keycloak, бэкапы.

Немного юмора

Я долго думал как назвать эту нотацию, в итоге остановился на Information Technology Infrastructure Topology — звучит как заклинание. А ещё аббревиатура по‑русски звучит прикольно ИТИТь‑колотить :) В самый раз, если сам инструмент моделирования называется Easy Breezy Architeezy!

Немного рекламы

У нас некоммерческий проект, мы заработали на нашем инструменте моделирования 0 рублей, а тратим немного больше и денег, и времени :) Между прочим, я все январские праздники потратил, чтобы придумать эту нотацию и «нарисовать» «красивейшие» SVG.

Понятно, что проект не может вечно существовать на энтузиазме, нам нужно продвигать и коммерческую составляющую, искать инвесторов, корпоративных заказчиков. В качестве первого шага мы зарегистрировались на Product Radar — они не заплатили нам за эту рекламу и не просили упоминать их, поэтому первоначальное утверждение про 0 рублей дохода всё ещё в силе :) Если у вас свой стартап‑проект, то я очень рекомендую там зарегистрироваться, за несколько дней я получил там больше предложений о сотрудничестве, чем за 1,5 года разработки до этого. Если не сложно, то поддержите наш проект в голосовании. Я думаю, это сильно поможет привлечь к нему внимание!

Также мы нашли на Product Radar ментора — Тигран Басеян. Мы его выбрали, потому что он сам руководит близким по смыслу проектом. Надеюсь, он поможет нам перейти от стадии стартапа к серьёзному продукту. На мой взгляд, у него полезный канал @blackproduct. Если вы развиваете свой проект, то наверняка найдёте много интересной информации. Например, я для себя уже нашёл там шаблон презентации для инвесторов.