W poprzednim poście opisałem jak działają niestandardowe slash commands: pliki markdown, $ARGUMENTS, frontmatter, namespace’owanie. Obiecałem kategorię devops jako kontynuację. Oto ona.

Katalog devops ma 12 komend. Skupię się na tych, które zastąpiły rzeczywiste dokumenty, które kiedyś utrzymywałem.

Problem z runbookami

Miałem runbooki. Strony w Confluence opisujące jak deployować, jak sprawdzić czy deployment poszedł źle, jak diagnozować błędy w każdej aplikacji. Niektóre były dobre. Większość była kilka miesięcy nieaktualna i musiałem w głowie patchować różnicę podczas ich śledzenia.

Runbook do deploymentu przez jakiś czas mówił “wejdź na dashboard Trigger i sprawdź status deploymentu” — już po tym, jak dodałem integrację z MCP, która pozwala mi to zrobić z CLI. Ciągle zapominałem aktualizować dokument. Dokument ciągle mnie okłamywał.

Komendy nie mają tego problemu. Jeśli zmieniam narzędzie używane do jakiegoś sprawdzenia, aktualizuję plik komendy. Plik komendy jest tym, co się wykonuje. Nie ma luki między dokumentacją a zachowaniem.

/deploy

To ta, której używam najczęściej. Zanim istniała, deployment tasków Trigger.dev to było pięć osobnych rzeczy do zrobienia po kolei, z czego połowę trzymałem w głowie.

Komenda najpierw równolegle uruchamia pre-deploy checks:

1
2
3
4
5

git status                         # working tree clean?
git log --oneline -5               # what's being deployed?
docker ps | grep trigger           # containers running?
mcp__trigger__list_deploys         # current deployed version
mcp__trigger__list_runs            # recent run status

Pokazuje mi to wszystko, a potem zatrzymuje się i pyta o potwierdzenie. Hooki uprawnień wymuszają tę bramkę automatycznie, więc nawet jeśli zapomnę dodać krok potwierdzenia, destrukcyjne komendy i tak zostaną zablokowane. Dopiero po tym jak powiem tak, SSH-uje na płytkę ARM i uruchamia właściwy deployment:

1
2

ssh user@server "cd ~/trigger-deploy && git pull && \
  npx [email protected] deploy --env prod"

Potem czeka 30 sekund i uruchamia post-deploy checks: czy pojawiła się nowa wersja, czy worker zarejestrował wszystkie taski, czy kontenery są nadal zdrowe.

Stary runbook to była strona w Confluence z nieaktualnymi zrzutami ekranu. To jest plik markdown z 42 liniami, który za każdym razem robi właściwą rzecz.

/diagnose

Ta jest bardziej ambitna. To pipeline wielu agentów do debugowania błędów aplikacji.

Uruchamiasz /diagnose myapp /var/log/myapp/error.log i ona:

  1. Wyciąga słowa kluczowe błędów z logu
  2. Przeszukuje Confluence w poszukiwaniu istniejących rozwiązań (używając sub-agenta confluence-searcher)
  3. Jeśli nic nie znajdzie, uruchamia trzy agenty równolegle: web research, szukanie dokumentacji bibliotek, przeszukiwanie codebase
  4. Przekazuje wszystko do agenta enterprise-app-specialist do analizy przyczyny źródłowej
  5. Proponuje utworzenie runbooka w Confluence lub lokalnego pliku markdown z wynikami
  6. Przygotowuje podsumowanie ticketa i krótki akapit dla osoby, która zgłosiła problem

Ta ostatnia część oszczędza mi najwięcej czasu. Pisanie “zidentyfikowaliśmy przyczynę jako X, zastosowaliśmy poprawkę Y, normalna praca przywrócona” pięć razy w tygodniu to dokładnie ten rodzaj zadania, który korzysta z szablonu. Agent to pisze, ja czytam, wysyłam.

Sam plik komendy ma około 150 linii. To bardziej skrypt orkiestracyjny niż komenda. Ale to nadal zwykły plik markdown z numerowanymi krokami i odwołaniami do narzędzi.

/trigger-status

Proste sprawdzenie statusu. Trzy kroki:

1
2
3

docker ps | grep trigger           # container health
mcp__trigger__list_runs            # last 10 runs, pass/fail
mcp__trigger__get_current_worker   # registered tasks

Wynikiem jest krótka tabela. Czy kontenery są zielone, współczynnik sukcesu runów, lista aktywnych tasków.

Uruchamiam to, kiedy coś nie wygląda dobrze albo chcę potwierdzić, że świeży deployment zarejestrował się poprawnie. Zajmuje około 15 sekund. Stary sposób to było otwieranie web UI Triggera, klikanie po trzech osobnych stronach i ręczne porównywanie tego, czego się spodziewałem.

/sys-health

Sześć sprawdzeń, wszystkie równolegle:

1
2
3
4
5
6

df -h /                                          # disk
free -h                                          # memory
uptime                                           # load average
docker ps | grep trigger                         # containers
docker ps --filter "health=unhealthy"            # anything broken
ss -tlnp | grep -E ':(80|443|3000|5432|8080)'   # key ports

Jedna zwarta tabela jako wynik. Cokolwiek powyżej 90% dysku lub jakikolwiek niezdrowy kontener jest oznaczany.

To jest tak proste jak komendy mogą być. Dwadzieścia linii łącznie z nagłówkiem i opisem użycia. Używam tego jako pierwszego kroku przed czymkolwiek innym, kiedy coś idzie nie tak.

/app-status

Ta jest per-aplikacja. Każda aplikacja, którą obsługuję, ma profil: nazwa, stack technologiczny, ścieżki do logów, label na GitHubie, przestrzeń w Confluence. Komenda ładuje profil dla aplikacji, którą przekazuję jako argument i pokazuje:

  • Otwarte issues na GitHubie z labelem tej aplikacji
  • Ostatnie strony w Confluence tej aplikacji (przez MCP)
  • Ostatnie pięć zdiagnozowanych problemów z lokalnego indeksu
  • Podsumowanie profilu aplikacji

To szybka orientacja przed rozpoczęciem sesji debugowania. Zamiast otwierać GitHub, otwierać Confluence i sprawdzać notatki, to /app-status myapp i mam wszystko w jednym miejscu.

Komendy dla konkretnych klientów

Trzy komendy obsługują konkretnych klientów lub środowiska: jedna dla konta AWS, jedna dla środowiska Azure z Kubernetes i MongoDB, jedna dla systemu produkcyjnego działającego na AWS.

Wszystkie idą tym samym wzorcem, ale z wbudowanym kontekstem specyficznym dla środowiska. Ta od Azure zna konkretne nazwy VM, reguły firewalla do sprawdzenia, konfigurację replica setu. Nie muszę nic z tego pamiętać. Komenda to niesie.

Każda z tych komend odwołuje się do pliku reguł specyficznego dla klienta, który zawiera rzeczy w stylu “zawsze weryfikuj status UFW przed dotykaniem iptables” albo “sprawdź zdrowie replica setu MongoDB przed restartem któregokolwiek członka.” Kontekst, który kiedyś żył w mojej głowie i czasem był zapominany.

Co zastąpiły

  • Runbook deploymentu w Confluence z nieaktualnymi zrzutami ekranu: /deploy
  • Mentalną checklistę “jak sprawdzić czy coś jest nie tak”: /sys-health i /trigger-status
  • Stronę wiki “kto obsługuje którą aplikację”, którą przestałem utrzymywać: /app-status
  • Trzy dokumenty runbook dla klientów, każdy 2-3 strony: trzy komendy dla klientów
  • Nawyk pisania podsumowań incydentów od zera za każdym razem: krok 6 /diagnose

Razem to około 400 linii markdown w 12 plikach. Strony w Confluence, które zastąpiły, miały pewnie łącznie 600 linii, napisane raz i powoli wypadające z synchronizacji.

Różnica nie jest w liczbie linii. W tym, że komendy się wykonują. Strony w Confluence tylko leżały.

Wzorzec, który nie zadziałał

Próbowałem zrobić jedną komendę /infra, która wykrywałaby kontekst i sama ustalała, w którym środowisku pracuję. “Jeśli jest konfiguracja Kubernetes, przyjmij środowisko Kubernetes. W przeciwnym razie sprawdź czy jest Docker.”

To było sprytne i było zawodne. Logika wykrywania często się myliła, a ja musiałem ją nadpisywać co drugi raz. Rozbiłem to na trzy jawne komendy dla klientów. Więcej plików, mniej zamieszania.

Wniosek jest nudny: jawne jest lepsze niż sprytne. Komenda, która zna swój własny kontekst, działa lepiej niż taka, która próbuje go zgadnąć.

Następnie

Kategoria Toggl to osiem komend owijających API do śledzenia czasu. Zupełnie inny charakter niż devops. Niektóre są tak proste, że prawie wstyd je pokazywać.