Стабильный стек DevOps
Эта книга больше не должна привязывать профессию к конкретному frontend-фреймворку. Фреймворки меняются, а инженерные задачи остаются: загрузить Linux, понять сеть, собрать артефакт, описать инфраструктуру, безопасно выкатить изменение, увидеть сбой и восстановить систему.
Основной стек
Заголовок раздела «Основной стек»| Уровень | Основа | Почему это долгоживущее знание |
|---|---|---|
| ОС | Linux, POSIX, systemd | процессы, права, файлы и сервисы лежат под большинством платформ |
| Shell | Bash и базовый POSIX shell | нужен для диагностики, CI и аварийных процедур |
| Сети | TCP/IP, DNS, HTTP, TLS, SSH | протоколы важнее конкретного облачного интерфейса |
| Контроль версий | Git | стандартный способ хранить и доставлять изменения |
| Автоматизация | Python | простой язык для CLI, API, glue-кода и проверок |
| Системные инструменты | Go | удобен для надёжных CLI, агентов и cloud-native инструментов |
| Данные | SQL и PostgreSQL | SQL и транзакционная модель переживают ORM и фреймворки |
| Артефакты | OCI-контейнеры и Docker/Podman | переносимая упаковка приложения с понятным контрактом |
| CI/CD | любой CI по принципам pipeline-as-code | конкретный SaaS меняется, стадии остаются |
| IaC | Terraform/OpenTofu и HCL | декларативная модель и state важнее названия провайдера |
| Оркестрация | Kubernetes после Linux/Docker | изучается как API и control loop, а не как набор команд |
| Наблюдаемость | логи, метрики, трассировки, SLO | это инженерные практики, а не бренд конкретного продукта |
Что не является фундаментом
Заголовок раздела «Что не является фундаментом»React, Next.js, NestJS, Prisma, Tailwind, Zustand, конкретный cloud provider, GitHub Actions, Helm, Grafana и Redis полезны в проектах, но не должны быть единственным способом объяснить тему. В книге они остаются в прикладном слое и сопровождаются альтернативой или стандартом:
- сначала HTTP, SQL и Unix-процессы, потом фреймворк;
- сначала OCI, namespaces и cgroups, потом удобная команда Docker;
- сначала Kubernetes API, scheduler и probes, потом Helm;
- сначала Terraform state и IAM, потом конкретный облачный provider;
- сначала OpenTelemetry/Prometheus-модель и SLO, потом конкретный dashboard;
- сначала OAuth 2.0, OIDC, TLS и cookie-модель, потом SDK конкретного провайдера.
Правило долговечности главы
Заголовок раздела «Правило долговечности главы»Каждая глава должна разделять материал на три слоя:
- Стандарт и модель. RFC, POSIX, SQL, OCI, Kubernetes API или фундаментальная концепция.
- Референсная реализация. Один выбранный инструмент с зафиксированной major-версией.
- Замена. Что поменять, если инструмент исчез, сменил лицензию или стал неуместен.
Команды проверяются в CI на зафиксированных версиях. В тексте указывается дата проверки, а пример не должен зависеть от latest, плавающего Docker-тега или непиннутого GitHub Action.
Рекомендуемый порядок
Заголовок раздела «Рекомендуемый порядок»Linux → Git → Bash → TCP/IP/DNS/HTTP/TLS → Python → SQL/PostgreSQL → OCI/Docker → CI/CD → Terraform/OpenTofu → Kubernetes → наблюдаемость и SRE → Go.
JavaScript и TypeScript нужны, если ты обслуживаешь Node.js-приложения или хочешь fullstack-маршрут. React и Next.js — отдельная специализация, а не обязательная ступень для DevOps.