Ops-автоматизация и скрипты

1) Зачем автоматизировать операции

Снижает MTTR/ошибки человека, ускоряет релизы и реакции.
Делает действия повторяемыми и аудируемыми (комплаенс).
Освобождает время инженеров для улучшений, а не рутины.

2) Основные принципы

1. Идемпотентность: повторный запуск → тот же результат.
2. Безопасные перила: dry-run, подтверждения, лимиты, авто-откаты.
3. Наблюдаемость: логи/метрики/трейсы встроены в каждый скрипт/пайплайн.
4. Конфигурация > константы в коде: все через параметры/манифесты.
5. GitOps/Docs-as-Code: код операций версионируется, ревьюится, тестируется.
6. Малые шаги: канареечные доли, батчи, ретраи с бюджетами.
7. Без секретов в репо: только через secret-хранилища.

3) Классы задач автоматизации

Ремедиация и инциденты: откаты, переключения провайдеров, фича-флаги деградации.
Плановые работы: ротации сертификатов/ключей, миграции БД (expand→migrate→contract).
Управление инфраструктурой: IaC (Terraform), конфигурации (Ansible), K8s манифесты.
Данные и DataOps: бэкфиллы, ETL, валидация качества.
Хаос/DR-учения: симуляции отказов с гейтами безопасности.

4) Как выбрать инструмент

Bash — короткие glue-скрипты, CLI-оркестрация.
Python — логика/SDK, ретраи, API, работа с JSON/YAML.
Ansible — идемпотентная конфигурация, агенты не нужны.
Terraform — декларативная инфраструктура.
Kubernetes Jobs/CronJobs — пакетные задачи/планирование.
Argo/Airflow — зависимые DAG-и и оркестрация.
ChatOps — безопасный запуск из чата с аудитом.

5) Архитектура автоматики (референс)

CLI/ChatOps → Контроллер (GitOps/оркестратор) → Исполнители (Ansible/Terraform/K8s Job) → Мониторинг (логи/метрики/трейсы) → Аудит/тикетинг → Док-артефакты (evidence).

6) Идемпотентность и управление состоянием

“Проверяй, затем меняй”: detect-then-act (если уже ОК — ничего не делай).
Храни “отметки выполнения” (state/lock) для длинных процедур.
Процедуры делите на атомарные шаги с возможностью повторного прогона.

7) Ошибки, ретраи и откаты

Ретраи с экспоненциальной задержкой и джиттером.
Бюджет времени операции (общее SLA на задачу).
Откаты и “стоп-кнопка” (circuit breaker) всегда предусмотрены.
Явные коды возврата и структурированные ошибки.

8) Безопасность и секреты

RBAC/ABAC, минимальные привилегии, временные токены (JIT/JEA).
Секреты из Vault/KMS/Cloud Secret Manager; ключи ротируются.
“Разделение обязанностей”: кто пишет — не тот, кто одобряет и запускает в проде.
Аудит-журнал: кто/когда/что/с каким результатом.

9) GitOps и ChatOps

PR → тесты → ревью → мердж → авто-промоция в среды.
Команды в чате (например, `/ops deploy checkout --canary 5%`) вызывают пайплайны; боты прикладывают evidence и ссылки на дашборды.

10) Планирование и оркестрация

CronJobs/DAG с зависимостями и дедлайнами.
Конкурентность: `Forbid`, `Replace`, `Allow` (K8s) в зависимости от задачи.
Политики ресурсов/квоты, чтобы не “съесть” прод.

11) Наблюдаемость автоматики

Метрики: успех/ошибка, длительность, ретраи, затронутые объекты.
Логи: структурированные, correlation-ID, красная строка на ошибке.
Трейсы: шаги долгих операций видны в распределенных трассировках.
Алерты: по симптомам (SLO) и по техническим метрикам (дедлайн, % ошибок).

12) Тестирование и симуляции

Юнит-тесты логики и парсеров артефактов.
Интеграционные тесты в песочнице и на канарейке.
“Тренажеры” (dry-run + фиктивные провайдеры), replay реальных сценариев.
Учения: четкие цели, гейты безопасности, AAR→RCA→CAPA.

13) Шаблоны кода

Bash (скелет с перилами)

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 (ретраи + идемпотентность)

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 (идемпотентная задача)

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: restarted

Kubernetes CronJob (плановая ротация)

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 }

GitHub Actions (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) Чек-лист внедрения

• Для каждой операции выбран инструмент и описан runbook.
• Есть dry-run, подтверждения и лимиты (перила).
• Логи структурированы, метрики и алерты подключены.
• Секреты из хранилища, доступы минимальные и временные.
• Тесты (юнит/интеграция/канарейка) и симуляции проведены.
• GitOps/PR-ревью обязательны, есть аудит.
• План отката и критерии успеха задокументированы.
• Автоматизация привязана к SLO/бюджетам ошибок.

15) Анти-паттерны

Скрипты без идемпотентности и откатов.
“Секреты в коде”, учетки-суперадмина на все.
Ручные правки в проде без аудита.
Кусковый Bash-зоопарк вместо декларативной IaC.
Параметры “зашиты” в код — нет переиспользования.
Нет dry-run/канареек → большие взрывы.
Логи “для людей” без структуры и кореляции.

16) Метрики зрелости Ops-автоматизации

Coverage: % операций с автоматизацией и runbook.
Success rate/Retry rate автоматических задач.
Mean time to execute (средняя длительность) и on-time (в дедлайн).
Change failure rate до/после автоматизации.
Аудит-полнота: % операций с полным evidence.
Секьюрити: время ротации ключей/сертификатов, доля JIT-доступов.

17) Итог

Ops-автоматизация — это не набор разрозненных скриптов, а система: идемпотентные действия, безопасные перила, наблюдаемость, секреты и доступы под контролем, GitOps/ChatOps, тесты и учения. В такой системе операции становятся быстрыми, предсказуемыми и аудируемыми — а бизнес получает стабильные релизы и низкий риск инцидентов.