LLM mají univerzální využití ve všech oblastech života, stejně tak i v DevOps. A protože v Cetinu před nějakou dobou vzniklo oddělení zaměřené na Ai, požádal jsem je o přístup k API v Azure OpenAI, čemuž bylo vyhověno. A protože mi bylo řečeno, že mám o svém Ai PoC v DevOps napsat nějaké pojednání, rozhodl jsem se, že toho rovnou využiji a napíšu ho jako post na svůj osobní blog. Předem bych rád uvedl, že jsem na testování neměl tolik času kolik bych si přál, protože mám spoustu prioritnějších úkolů, než se naplno věnovat Ai v DevOps.
PoC závěry využití Ai v DevOps
Prvotním hybatelem pro využití Ai v DevOps byla snaha o řešení problematiky DevSecOps. Zde jsou velkým problémem velmi vysoké náklady na bezpečnostní software, které považuji až za nemravné, ale ono se není čemu divit. Krom toho, že securitu je nutné tak jako tak řešit, tak poslední dobou se veze na hype vlně, což znamená, že vše je zpravidla dražší, než by normálně bylo. Mimo to, fakt, že skutečných bezpečnostních profesionálů je extrémně málo, dělá z těchto lidí stojící často za bezpečnostním softwarem, lidi placené "zlatem". Přesto všechno bývá občas špičkový bezpečnostní software dostupný zdarma, nicméně většinou ne pro firemní použití. Z toho důvodu využíváme nějaké programy jen v komunitní/free verzi, které nabízí pro naše lidi klíčové funkcionality zdarma. A zde mě právě napadlo, že by nám mohla Ai pomoci. Ona totiž umí poměrně solidně analyzovat předložený kód a v něm hledat problémové paterny. A nejen to, že je najde, ale rovnou je schopna nabídnout možná řešení. A přestože LLM není bezpečnostní software a není možné na ni ani tak nahlížet, tak je to pořád lepší než nemít nic. Nakonec kdo říká, že draze placený bezpečností software nutně dělá svoji práci tak jak má a že podchytí všechny známé problémy.
Další možné využití mě napadlo, když jsme si měli připravit ukázku naší práce na Offsite, kde jsme letos dostali prostor. Napadlo mě totiž, že bychom mohli logy z proběhlých pipeline v posledním jobu nechat analyzovat Ai. Důvod proč mě to napadlo byl následující. Stává se, že například Bash skript, který se spouští, není napsaný úplně ideálně s ohledem na běh v pipeline, a tak někdy proběhne tak, že sice skončí chybou, ale tato chyba není zpropagována ze skriptu ven do pipeliny. Jednoduše skript vrátí návratový kód 0, místo jiného, který by způsobil chybu v běhu jobu. Job se pak tváří, že proběhl v pořádku (vše je zelené), ale vy se divíte, že nedoběhl tak jak by měl. A protože logy někdy mohou být po čertech dlouhé a člověk je tvor chybující, je lepší nechat logy zkontrolovat nějaký nástroj, v tomto případě Ai, která se na to ideálně hodí. A skutečně, LLM, přestože není dokonalá, tak nepřehlédne nic a v posledním jobu, pokud narazí na nějaké rozpory v logách, vyvolá chybu běhu jobu pipeline a napíše rovnou proč. Za mě je tohle natolik dobré využití Ai v DevOps, že bych všechny pipeline "by default" obohacoval takovouto závěrečnou analýzou.
Jako poslední PoC, na které jsem však zatím neměl čas, ale rozhodně se mu budu věnovat, je využití metody RAG k vylepšení odpovědí Ai. RAG, neboli Retrieval-Augmented Generation, je metoda v umělé inteligenci, která vylepšuje výkon velkých jazykových modelů (LLM) tím, že je doplňuje o externí zdroje informací. Tímto způsobem RAG zajišťuje, že LLM generují přesnější, relevantnější a aktuálnější odpovědi. Zde by stálo za to, vyzkoušet vytvoření malých datasetů, které by se LLM předložily spolu s otázkou. Například pro DevOps, které intenzivně pracuje s Linuxem, by bylo dobré vytvořit set detailních pravidelně aktualizovaných informací o Linuxu a nástrojích, které používáme, k tomu, abychom při hledání řešení našich problémů dostali relevantnější odpovědi. On je totiž velký rozdíl v tom, když se zeptáte takto "Nefunguje mi Podman v Linuxu, co může být problémem?", nebo třeba takto "Nefunguje mi Podman 5.2.2 v RHEL 9, co může být problémem?". Přestože se jedná o primitivní dotazy, je často klíčové uvést třeba ty verze programů, se kterými pracujete. A to zadávat ručně je problém. LLM je bezestavový a v průběhu konverzace zapomíná a vy mu musíte dokola připomínat o čem se mluví. Toto je markantní zejména při použití API, kde v každém dotazu buď musíte posílat celou předchozí komunikaci, což je nákladné z hlediska tokenizace, za kterou platíte, protože s každým dotazem odesíláte čím dál delší dotaz, který má také své limity a není možné odeslat extrémně dlouhou konverzaci, byť dnešní modely zvládají zpracovat hodně textu v jednom dotazu. Takže se nakonec musíte uchylovat k sumarizaci, čímž šetříte tokeny a také svůj budget.
K samotné implementaci API do pipeline není potřeba psát asi nic konkrétního. Komunikace je velmi primitivní, využívající JSON a specifickou strukturu dotazu definovanou dokumentací. Ta se odešle přes curl na server a odpověď si pak zpracujete. U asynchronních dotazů pak pomocí vráceného ID se ve smyčce testuje status dotazu a čeká se na jeho dokončení.
Zde je jednoduchá ukázka z PoC, ve které se odešlou logy k analýze a čeká se na odpověď.
1. PROMPT="Analyzuj následující logy Azure Pipeline a napiš, zda obsahují chyby nebo jiné anomálie. Pokud je vše v pořádku, napiš \\\"Ai nenašla žádné chyby\\\". Logy:\n"
2. CONTENT=$( { echo -e "$PROMPT"; cat log.txt; } | jq -Rs . )
3.
4. read -r -d '' data << EOM
5. {
6. "messages": [
7. {
8. "role": "user",
9. "content": $CONTENT
10. }
11. ]
12. }
13. EOM
14.
15. printf "%s\n" "$data" > request.json
16.
17. response=$(curl -s --fail --header "Content-Type: application/json" \
18. --header "api-key: $AI_TOKEN" \
19. --request POST \
20. --data "$data" \
21. $API_ENDPOINT)
22.
23.
24. Zde je odpověď.
25.
26. ### 1. **Trigger Configuration:**
27. - Trigger a PR jsou nastaveny na `branches: include - none`. To znamená, že pipeline není spuštěna automaticky při změnách v žádné větvi.
28. - Toto není chyba, ale je třeba ověřit, zda je tento úmysl v souladu s požadavky projektu.
29.
30. ### 2. **Stahování tajemství z Azure Key Vault:**
31. - Všechny tajné klíče (`ssh-key`, `openai-token-for-testing` atd.) byly úspěšně staženy z Azure Key Vault bez problémů.
32. - Žádné chyby ani anomálie zde nenalezeny.
33.
34. ### 3. **Ansible Playbook Execution:**
35. - Playbook se úspěšně spustil na cílové serverové skupině.
36. - Úkoly jsou správně spuštěny, některé jsou přeskočeny, což je v souladu s konfigurací (`skipped`) nebo obsahují operace s úspěšným výstupem (`changed`, `ok`).
37. - Např. služby jako `filebeat`, `gitlab`, `vault`, `postgresql-devops` byly úspěšně povoleny a spuštěny.
38. - Gitlab API pro liveness a readiness vrací správný status: `ok`.
39.
40. ### 4. **Pipeline Trigger:**
41. - Akce spouštění pipeline se zdá být správně nakonfigurována.
42.
43. ### 5. **Integrace s Reverse AI:**
44. - Skript pro Reverse AI správně generuje požadavek a získává odpověď, ovšem není jasné, jaká byla odpověď Reverse AI. Pokud odpověď byla prázdná („No response from AI.), je to možné riziko, ale pipeline pravděpodobně nebyla tímto ovlivněna (logy neobsahují kritické chyby).
45.
46. ### 6. **Kontrolní mechanismy chyb:**
47. - Několik kroků obsahuje kontrolní mechanismy k selhání (`exit 1`) či upozornění (např. v případě nesprávné skupiny Gitlab), které umožňují předčasné ukončení v případě neúspěšných stavů. Tyto nebyly během provádění pipeline aktivní.
48.
49. ### 7. **Vývojářské varování v Ansible:**
50. - Ansible upozorňuje na možné budoucí problémy s definicí Python interpreteru (`/usr/bin/python3.9`). Toto však zatím není kritická chyba, ale vhodné je toto sledovat a případně upravit konfiguraci.
51.
52. ### **Závěr:**
53. Ai nenašla žádné chyby.