Problemem nie są narzędzia, tylko kolejność
Większość inicjatyw DevOps w średnich firmach pada tak samo: zespół instaluje Terraform, buduje piękne repo IaC, a po pół roku odkrywa, że serwery pod spodem są nadal konfigurowane ręcznie i nikt nie wie w jakim są stanie. Repo opisuje fikcję.
Ten tekst opisuje kolejność, którą rzeczywiście rekomendujemy w 2026 dla zespołu opiekującego się 5–100 serwerami, mix chmury i on-premu. To nie jest najbardziej ambitna sekwencja — to ta, która przeżywa kontakt z rzeczywistością.
Plan
- Zacznij od config managementu (Ansible) przed IaC (Terraform)
- Wersjonuj wszystko: infra, configi, runbooki
- Minimalne CI/CD
- Sekrety bez domowych vaultów
- Observability od pierwszego dnia
- Pułapki, które zabijają DevOps małych zespołów
- 60-dniowy plan automatyzacji
1. Najpierw config management, dopiero potem IaC
Terraform odpowiada „jaka infrastruktura istnieje?”. Ansible (lub odpowiednik) odpowiada „co jest na każdej maszynie?”. Dla istniejącego estate to drugie pytanie jest bolesne — i ma największy zwrot. Przejdź estate Ansiblem:
- Zinwentaryzuj każdy serwer jednym playbookiem.
- Wymuś rolę baseline (użytkownicy, SSH, NTP, agent monitoringu).
ansible-playbook --checkjako element każdej zmiany.- Dopiero potem ściągaj provisioning do Terraforma.
Zespół, który jednym poleceniem przeprowadza baseline na całym estate, ma większą dojrzałość operacyjną niż zespół z błyszczącym repo Terraforma i nieśledzonym driftem.
2. Wersjonuj wszystko
Kod infrastruktury, role konfiguracyjne, runbooki, dashboardy, definicje alertów, nawet szablon grafiku on-call. Jedna organizacja w Git, jeden CODEOWNERS, obowiązkowe PR-y dla wszystkiego co dotyka produkcji. Struktura nudna:
/infra # Terraform
/config # role Ansible + inventory
/runbooks # markdown, jeden per klasa incydentu
/observability # dashboardy jako kod, reguły alertów
Jeśli zmiana jest na tyle ciekawa, by ją wprowadzić — jest na tyle ciekawa, by ją zreviewować. To najtańszy control-plane, jaki kiedykolwiek zbudujesz.
3. Minimalne CI/CD
Zapomnij o ośmiu etapach na pierwszą wersję. Minimum:
- Build — kompilacja, paczka, image kontenera z digestem.
- Test — unit, integration, skan bezpieczeństwa (np. Trivy na image).
- Deploy na staging — automatycznie z
main. - Deploy na produkcję — manualna akceptacja, jeden klik.
- Rollback — jeden przycisk, testowany co miesiąc.
Ten ostatni krok dzieli prawdziwy pipeline od aspiracji. Jeśli nie potrafisz cofnąć zmiany bez zebrania zespołu — to nie jest pipeline.
4. Sekrety bez domowych vaultów
Wybierz jedno: HashiCorp Vault, Doppler, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager. Spnij z Ansiblem, Terraformem i CI. Rotuj credentiale maszynowe automatycznie; ludzkie — przy offboardingu. Nigdy nie trzymaj sekretów w plikach env w Git, nawet zaszyfrowanych — ergonomia operacyjna zawsze upada i ktoś zacommituje cleartext.
5. Observability od pierwszego dnia
Potrzebujesz trzech rzeczy w tej kolejności:
- Metryki (Prometheus + Grafana lub odpowiednik hosted) — capacity, saturation, errory.
- Logi (Loki, Elastic, hosted) — forensyka incydentów.
- Ślady (Tempo, Jaeger, hosted) — wszystko user-facing.
Najpierw dashboardy, potem alerty. Alert tylko wtedy, gdy istnieje runbook. Alert bez runbooka to pager budzący człowieka bez czytelnej akcji.
6. Pułapki, które zabijają DevOps małych zespołów
| Pułapka | Dlaczego zabija |
|---|---|
| Over-engineering | Kubernetes dla trzech serwisów; service mesh dla dwóch podów. |
| „Snowflake” serwery | Jeden krytyczny host, którego nikt nie dotyka, pełen ręcznej konfiguracji. |
| Brak testów rollbacka | Pierwszy realny rollback w trakcie awarii. |
| Mnożenie narzędzi | Trzy vaulty, dwa IaC, dwa stosy observability. |
| Dokumentacja w głowach | Bus factor jeden. |
Lekarstwo na każdą jest nudne: mniejsza powierzchnia, powtarzalne deploye, miesięczne drille, jedno narzędzie do jednej roli, zapisuj.
7. 60-dniowy plan automatyzacji
- Tydzień 1–2 — Inwentaryzacja: jeden playbook Ansible opisujący cały estate.
- Tydzień 3–4 — Rola baseline na wszystkich hostach. Raport driftu co tydzień.
- Tydzień 5–6 — CI dla najczęściej zmienianej aplikacji. Build + test.
- Tydzień 7–8 — Krok deploy z manualną akceptacją. Rollback przetestowany.
- Tydzień 9–10 — Sekrety scentralizowane. Dwa najbardziej ryzykowne credentiale zrotowane.
- Tydzień 11–12 — Metryki + logi w jednym miejscu. Trzy actionable alerty z runbookami.
Tyle wystarcza, by zmienić charakter operacyjny małego zespołu. Wszystko po tygodniu 12 to iteracje na tym fundamencie.
Rekomendowany toolchain dla małego zespołu w 2026
- Config: Ansible
- IaC: Terraform (lub OpenTofu)
- CI/CD: GitHub Actions lub GitLab CI
- Kontenery: Docker; Kubernetes tylko gdy naprawdę trzeba
- Sekrety: Vault, Doppler lub KMS Twojej chmury
- Observability: stos Grafany (Prometheus + Loki + Tempo) lub hosted odpowiednik
Celowo bez blasku. Blask zabija DevOps w firmach poniżej 200 osób.
Kluczowe wnioski
- Najpierw ujarzmij to co istnieje config managementem, dopiero potem opisuj ideał w IaC.
- Wersjonuj razem infrastrukturę, runbooki, dashboardy i reguły alertów.
- Minimalne CI/CD zawiera przetestowany rollback. Bez niego to aspiracja.
- Sekrety centralizuj wcześnie; observability w kolejności metryki → logi → ślady.
- Sześć tygodni dyscypliny zmienia charakter operacyjny zespołu bardziej niż sześć miesięcy zakupów narzędzi.
Jeśli chcesz drugą opinię od inżyniera o Twoim roadmapie DevOps lub kickoff automatyzacji o stałym zakresie — napisz do nas. Rozmawiasz z inżynierem, nie ze sprzedażą.