Automatyzacja ops i skrypty
1) Dlaczego automatyzacja operacji
Zmniejsza błąd MTTR/ludzkiego, przyspiesza uwalnianie i reakcje.
Czyni działania powtarzalnymi i audytowymi (zgodność).
Uwalnia czas inżynierów na poprawę, a nie rutynowe.
2) Podstawowe zasady
1. Idempotencja: rerun → ten sam wynik.
2. Poręcze bezpieczeństwa: suche, potwierdzenia, limity, automatyczne rolki.
3. Obserwowalność: dzienniki/mierniki/szlaki są wbudowane w każdy skrypt/rurociąg.
4. Konfiguracja> stałe w kodzie: wszystkie za pomocą parametrów/manifestów.
5. GitOps/Docs-as-Code: kod transakcji jest zmieniany, sprawdzany, testowany.
6. Małe kroki: płaty kanaryjskie, partie, przekładki z budżetami.
7. Brak tajemnic w repo: tylko przez tajne magazyny.
3) Klasy zadań automatyzacji
Rekultywacja i incydenty: rolki, przełączniki dostawców, flagi funkcji degradacji.
Planowana praca: rotacja certyfikatów/kluczy, migracja bazy danych (rozwiń → migrate → contract).
Zarządzanie infrastrukturą: IaC (Terraform), konfiguracje (Ansible), manifesty K8s.
Dane i Ops: zasypki, ETL, walidacja jakości.
Ćwiczenia Xaoc/DR: symulacja awarii z bramkami bezpieczeństwa.
4) Jak wybrać narzędzie
Bash - krótkie skrypty klejowe, orkiestra CLI.
Python - logika/SDK, retrai, API, praca z JSON/YAML.
Dowolna - idempotentna konfiguracja, brak agentów.
Terraform jest infrastrukturą deklaracyjną.
Kubernetes Jobs/CronJobs - zadania wsadowe/harmonogram.
Argo/Airflow - zależne DAGs i orkiestra.
ChatOps - bezpieczny start z czatu z audytem.
5) Architektura automatyzacji (odniesienie)
CLI/ChatOps → Kontroler (GitOps/Orchestrator) → Wykonawcy (Ansible/Terraform/K8s Job) → Monitoring (logs/metrics/trails) → Audyt/biletowanie → Dokowanie artefaktów (dowody).
6) Zarządzanie idempotencją i stanem zdrowia
„Sprawdź, a następnie zmień”: detect-then-act (jeśli już OK - nic nie rób).
Przechowywać „stan/blokadę” dla długich procedur.
Podziel procedury na stopnie atomowe z możliwością powtórnego przebiegu.
7) Błędy, cofnięcia i rolki
Retrai z wykładniczym opóźnieniem i jitter.
Budżet czasu operacji (całkowity SLA na zadanie).
Rolki i wyłącznik są zawsze zapewnione.
Wyraźne kody zwrotne i ustrukturyzowane błędy.
8) Bezpieczeństwo i tajemnice
RBAC/ABAC, minimalne uprawnienia, tymczasowe żetony (JIT/JEA).
Sekrety od Vault/KMS/Cloud Secret Manager; klucze są obracane.
„Rozdzielenie obowiązków”: kto pisze, nie jest tym, który zatwierdza i uruchamia prod.
Dziennik audytu: kto/kiedy/co/z jakim wynikiem.
9) GitOps - ChatOps
PR → testy → przegląd → scalenie → auto-promocja do środowisk.
Polecenia w czacie (na przykład '/ops deploy checkout --canary 5% ') powodują rurociągi; boty stosują dowody i linki do desek rozdzielczych.
10) Planowanie i orkiestra
CronJobs/DAG z zależnościami i terminami.
Konkurencja: „Zakazać”, „Zastąpić”, „Pozwolić” (K8s) w zależności od zadania.
Polityki/kwoty zasobów, aby nie „jeść” prod.
11) Obserwowalność automatyzacji
Metryka: sukces/błąd, czas trwania, przekładki, dotknięte obiekty.
Dzienniki: struktura, korelacja-ID, czerwona linia na błędzie.
Ślady: Etapy długich operacji widoczne są w rozłożonych śladach.
Ostrzeżenia: przez objawy (SLO) i przez metryki techniczne (termin,% błędów).
12) Badania i symulacje
Testy jednostkowe parserów logicznych i artefaktowych.
Testy integracyjne w piaskownicy i kanarkach.
„Symulatory” (suchy-run + manekiny dostawców), powtórzyć prawdziwe scenariusze.
Ćwiczenia: jasne cele, bramy bezpieczeństwa, AAR → RCA → CAPA.
13) Szablony kodów
Bash (szkielet z balustradami)
bash
!/usr/bin/env bash set -Eeuo pipefail trap 'echo "[ERR] line $LINENO"; exit 1' ERR
log(){ printf '%s %s\n' "$(date -Iseconds)" "$"; }
DRY=${DRY_RUN--true}
ensure_dep(){ command -v "$1" >/dev/null { echo "need $1"; exit 2; }; }
apply_change(){
local target="$1"
if [[ "$DRY" == "true" ]]; then log "[DRY] would update $target"
else kubectl apply -f "$target"
fi
}
main(){
ensure_dep kubectl for f in manifests/.yaml; do apply_change "$f"
done log "done"
}
main "$@"Python (Retrai + Idempotencja)
python import argparse, time, json, sys from pathlib import Path import requests
def with_retries(fn, attempts=5, base=0. 2):
for i in range(attempts):
try:
return fn()
except Exception as e:
sleep = base (2i)
time. sleep(sleep)
raise
def already_done(marker):
return Path(marker). exists()
def mark_done(marker):
Path(marker). write_text("ok")
def main():
ap = argparse. ArgumentParser()
ap. add_argument("--endpoint", required=True)
ap. add_argument("--marker", default="/tmp/op. marker")
args = ap. parse_args()
if already_done(args. marker):
print("idempotent: nothing to do"); return
def call():
r = requests. post(args. endpoint, json={"action":"rotate"})
r. raise_for_status()
return r. json()
resp = with_retries(call)
print(json. dumps(resp))
mark_done(args. marker)
if __name__ == "__main__":
sys. exit(main())Ansible (zadanie idempotentne)
yaml
- hosts: web become: true tasks:
- name: Ensure nginx present and enabled ansible. builtin. package:
name: nginx state: present
- name: Deploy config ansible. builtin. template:
src: nginx. conf. j2 dest: /etc/nginx/nginx. conf mode: '0644'
notify: restart nginx handlers:
- name: restart nginx ansible. builtin. service:
name: nginx state: restartedKubernetes CronJob (planowana rotacja)
yaml apiVersion: batch/v1 kind: CronJob metadata:
name: cert-rotate spec:
schedule: "0 3 "
concurrencyPolicy: Forbid jobTemplate:
spec:
template:
spec:
serviceAccountName: ops-automation restartPolicy: OnFailure containers:
- name: rotator image: registry/ops/rotator:1. 2. 3 args: ["--rotate", "--budget-ms=60000"]
envFrom:
- secretRef: { name: rotator-secrets }Akcje GitHub (wyzwalacz ChatOps)
yaml name: ops-deploy on:
workflow_dispatch:
inputs:
service: {required: true}
canary: {required: false, default: "5"}
jobs:
deploy:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- run:./scripts/deploy. sh "${{ inputs. service }}" --canary "${{ inputs. canary }}"14) Lista kontrolna wdrażania
- Wybrano narzędzie dla każdej operacji i opisano książkę startową.
- Istnieją suche biegi, potwierdzenia i limity (balustrady).
- Rejestry są ustrukturyzowane, podłączone są mierniki i wpisy.
- Tajemnice przed przechowywaniem, minimalny i tymczasowy dostęp.
- Przeprowadzone badania (jednostka/integracja/kanarka) i symulacje.
- GitOps/PR recenzje są wymagane, jest audyt.
- Plan wycofania i udokumentowane kryteria sukcesu.
- Automatyzacja jest związana z budżetami SLO/błędów.
15) Anty-wzory
Skrypty bez idempotencji i wałków.
„Sekrety w kodzie”, superadmin odpowiada za wszystko.
Ręczne edycje w sprzedaży bez audytu.
Chunky Bash Zoo zamiast deklaratywnego IaC.
Parametry „chronione” w kodzie - brak ponownego użycia.
Brak suchych biegów/kanarów → duże eksplozje.
Dzienniki „dla ludzi” bez struktury i korelacji.
16) Metryki dojrzałości automatyki operacyjnej
Zasięg:% operacji automatyki i runbooka.
Wskaźnik sukcesu/szybkość powtarzania zadań automatycznych.
Czas na egzekucję i na czas.
Zmień wskaźnik awarii przed/po automatyzacji.
Kompletność audytu:% operacji z pełnymi dowodami.
Bezpieczeństwo: czas rotacji klucza/certyfikatu, udział dostępu JIT.
17) Sedno sprawy
Automatyzacja ops to nie zestaw rozbieżnych skryptów, ale system: idempotentne działania, bezpieczne balustrady, obserwowalność, tajemnice i dostęp pod kontrolą, GitOps/ChatOps, testy i ćwiczenia. W takim systemie operacje stają się szybkie, przewidywalne i kontrolne - a firma otrzymuje stabilne zwolnienia i niskie ryzyko incydentów.