Uwagi praktyczne: Od wzorca do pipeline’a: wdrażanie Agentic Cortex z
Krok po kroku praktyczne wskazówki: Od wzorca do pipeline’a: wdrażanie Agentic Cortex z wykorzystaniem umów, sprawdzeń oraz gotowych miejsc na kod dla zespołów wdrażających ten wzorzec.
Źródła: From Pattern to Pipeline: Implementing the Agentic Cortex with LangGraph and OPA
Poniższe notatki przedstawiają praktyczną ścieżkę postępowania w ramach tematu „Od wzorca do pipeline: wdrażanie Agentic Cortex za pomocą LangGraph i OPA”. Nacisk kładziony jest na umowy, sprawdzania oraz miejsca na kod do wstawienia, a nie na motywacyjne aspekty. Podczas przechodzenia przez etap przeglądu najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zdokumentuj zarówno ścieżkę prawidłowego działania, jak i ścieżkę naprawczą. Próby ponowne, ludzkie kontrolery oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dopiero późniejszej optymalizacji.
Przegląd architektury:
Etap przeglądu architektury działa najlepiej, gdy traktuje się go jako mierzalną powierzchnię. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres pracy. Wolno preferować małe, testowalne jednostki zamiast rozbudowanych skryptów. Gdy jakiś krok zawiedzie, awaria powinna wskazywać na konkretną odpowiedzialność, a nie na skomplikowany łańcuch operacji. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wtórne struktury ukrywają informację o tym, który węzeł zapisał dane do którego pola, i powodują przerwanie kontynuacji po przerwach.
Łańcuch operacji: sześć węzłów, jeden StateGraph
Faza Pipeline Six Nodes funkcjonuje najlepiej, gdy traktowana jest jako mierzalna powierzchnia. Zapisz jeden idealny przepis, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań, zanim rozszerzysz zakres pracy. Traktuj tę fazę jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzuć ciche, częściowe ukończenie zadań. Utrzymuj stan grafu w prostej formie i określonej typowości. Wkładki nawiasowe ukrywają informację o tym, który węzeł zapisał dane w danym polu, co powoduje przerwanie kontynuacji po przerwach.
class CortexState(TypedDict, total=False):
domain_outputs: Dict[str, DomainOutput]
normalized_recommendations: List[NormalizedRecommendation]
cross_domain_conflicts: List[CrossDomainConflict]
policy_decisions: List[PolicyDecision]
resolved_conflicts: List[CrossDomainConflict]
sentinel_check: Optional[SentinelCheckResult]
final_recommendations: List[NormalizedRecommendation]
workflow = SateGraph(CortexState)
workflow.add_node("collect_domains", domain_collector_agent)
workflow.add_node("evaluate_mesh", mesh_evaluator_agent)
workflow.add_node("apply_policies", policy_engine_agent)
workflow.add_node("resolve_conflicts", conflict_resolver_agent)
workflow.add_node("sentinel_check", sentinel_loop_agent)
workflow.add_node("generate_report", report_generator_agent)workflow.set_entry_point("collect_domains")
workflow.add_conditional_edges("collect_domains",
should_continue_after_collection,
{"evaluate_mesh": "evaluate_mesh", "end": END})
Węzeł 1: Zbieracz domen
Faza Node 1 The Domain funkcjonuje najlepiej, gdy jest traktowana jako mierzalna powierzchnia. Zapisz jeden idealny zapis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres. Zapisuj czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy ścieżka przechodzi z wersji demonstracyjnej do środowisk współdzielonych. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wplecione struktury ukrywają informację o tym, który węzeł zapisał dane w danym polu, i powodują przerwę w kontynuacji działania po zakłóceniach. Faza Node 1 The Domain funkcjonuje najlepiej, gdy jest traktowana jako mierzalna powierzchnia. Zapisz jeden idealny zapis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres. Zdokumentuj zarówno ścieżkę prawidłowego działania, jak i ścieżkę przywracania do normalnego stanu. Próby ponownych działań, kontrolne punkty ludzkie oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później.
AGENT_A_URL = "http://localhost:8001"
AGENT_B_URL = "http://localhost:8002"
Node 2: The Mesh Evaluator, Where Conflicts Surface
Dla etapu Mesh w węźle 2 należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić dany krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy preferować małe, łatwe do przetestowania jednostki zamiast rozbudowanych skryptów. Gdy dany krok zawiedzie, powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowany łańcuch operacji. Konieczne jest ludzkie zatwierdzenie dla działań, które wiążą się z wydatkami lub modyfikacją danych produkcyjnych. Połączenia realizowane w czasie kompilacji nie równają się kompletności biznesowej.
{
"conflict_type": "budget_reliability_tradeoff",
"severity": "HIGH",
"resource_id": "resource-x",
"recommendation_a": {"domain": "domain_a",
"title": "Decommission idle resource-x"},
"recommendation_b": {"domain": "domain_b",
"title": "Enable redundancy for resource-x"}
}
Wynik Mesh = (Pewność × 100) + Bonus za powagę problemu — Kary za konflikty
W fazie Mesh Score Confidence X należy zdefiniować dane wejściowe, osobę odpowiedzialną za daną krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Traktuj tę fazę jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nazwij powstałe pliki, zdefiniuj kryteria sukcesu i odrzuć ciche, częściowe ukończenie zadania. Wymagaj ludzkiej aprobaty w przypadku operacji, które wiążą się z wydawaniem pieniędzy lub modyfikacją danych produkcyjnych. Połączenia realizowane w czasie kompilacji nie równają się pełnej kompletności biznesowej.
Węzeł 3: Silnik polityk OPA, deterministyczne zarządzanie
Dla etapu OPA w Node 3 należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Zapisuj czas trwania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy ścieżka przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Wprowadź ludzką aprobatę dla operacji, które generują wydatki lub zmieniają dane produkcyjne. Podłączenia realizowane w czasie kompilacji nie gwarantują pełnej kompletności rozwiązania biznesowego. Dla etapu OPA w Node 3 należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Dokumentuj zarówno ścieżkę prawidłowego działania, jak i ścieżkę naprawczą. Próby ponownych działań, mechanizmy ludzkiej kontroli oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później.
Architektura OPA Sidecar
Podczas prace nad etapem architektury OPA Sidecar najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Wolno preferować małe, testowalne jednostki zamiast rozbudowanych skryptów. Gdy jakiś krok się nie powiedzie, błąd powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowany łańcuch operacji. Ustaw punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji nie powinno ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
package cortex.recommendation
decision := result if {
_is_destructive_action(input.recommendation.title)
_is_critical_resource(input.recommendation.resource_id,
input.context)
result := {
"decision": "deny",
"reason": "Policy prevents decommissioning
of critical resource",
"rule_name": "protect_critical_resources"
}
}
package cortex.conflict
# Budget vs Reliability on critical resources gets policy override
resolution := result if {
input.conflict.conflict_type == "budget_reliability_tradeoff"
_is_critical_resource(input.conflict.resource_id, input.context)
result := {
"strategy": "policy_override",
"winner": _higher_ranked_domain(...),
"rule_name": "budget_reliability_critical_resource"
}
}# Resource Contention resolved by domain priority for unequal ranks
resolution := result if {
input.conflict.conflict_type == "resource_contention"
domain_rank[...] != domain_rank[...]
result := {
"strategy": "domain_priority",
"winner": _higher_ranked_domain(...),
"rule_name": "resource_contention_priority"
}
}# Opposing Recommendations on critical resources are escalated
resolution := result if {
input.conflict.conflict_type == "opposing_recommendations"
_is_critical_resource(...)
result := {
"strategy": "escalate",
"winner": "none",
"rule_name": "opposing_critical_escalate"
}
}
package cortex.priority
domain_rank := {
"domain_a": 1,
"domain_b": 2,
"domain_c": 3,
"domain_d": 4,
"domain_e": 5
}
services:
opa:
image: openpolicyagent/opa:latest
command: run --server --addr=0.0.0.0:8181 /policies
volumes:
- ./src/policies:/policies
Węzeł 4: Rozwiązywacz konfliktów, czterostopniowe rozwiązanie
Gdy przechodzisz przez etap Node 4 The Conflict, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzuć możliwość cichego, częściowego ukończenia zadania. Ustaw punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji nie powinno ponownie naliczać opłat za tę samą próbę wywołania LLM, gdy operator ponawia działanie w późniejszym etapie.
Hierarchia rozwiązywania konfliktów w czterech etapach
Gdy przechodzisz przez etap czterostopniowego rozwiązywania konfliktów, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zapisz czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy proces przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Ustal punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji nie powinno ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł. Gdy przechodzisz przez etap czterostopniowego rozwiązywania konfliktów, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zdokumentuj zarówno ścieżkę prawidłowego działania, jak i ścieżkę naprawczą. Próby ponownych wywołań, kontrolne punkty ludzkie oraz obsługa wiadomości błędowych są częścią produktu, a nie elementami dodatkowej optymalizacji.
{
"winner": "a" | "b" | "both",
"reasoning": "...",
"confidence": 0.0-1.0
}
Węzeł 5: Pętla Strażnika, wykrywanie odchylenia pomiędzy cyklami
Faza Węzła 5 „Strażnik” funkcjonuje najlepiej, gdy traktowana jest jako mierzalna powierzchnia. Zapisz jeden idealny przekaz, jeden przypadek awarii oraz notatkę o cofnięciu działań przed rozszerzaniem zakresu. Wolno preferować małe, testowalne jednostki zamiast rozbudowanych skryptów. Gdy jakiś krok zawiedzie, awaria powinna wskazywać na konkretną odpowiedzialność, a nie na skomplikowany łańcuch operacji. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wplecione struktury ukrywają informację o tym, który węzeł zapisał dane do którego pola, co utrudnia kontynuację pracy po przerwach.
change_percent = (current - previous) / abs(previous) * 100
if abs(change_percent) > DRIFT_THRESHOLD_PERCENT:
drift_status = "WORSENED" if change_percent < 0
else "DRIFTED"
Węzeł 6: Generator raportów
Faza Node 6 The Report funkcjonuje najlepiej, gdy traktowana jest jako mierzalna powierzchnia. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres pracy. Traktuj tę fazę jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzuć przypadki częściowego ukończenia pracy bez informacji.
Pełny scenariusz demonstracyjny
Faza „The Full Demo Scenario” funkcjonuje najlepiej, gdy traktowana jest jako mierzalna powierzchnia do analizy. Zapisz jeden idealny zapis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres testów. Zarejestruj czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy przechodzi się od środowiska demonstracyjnego do współdzielonych środowisk. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wplecione elementy ukrywają informację o tym, który węzeł zapisał dane do którego pola, co powoduje przerwę w kontynuacji działania po zakłóceniach. Faza „The Full Demo Scenario” funkcjonuje najlepiej, gdy traktowana jest jako mierzalna powierzchnia do analizy. Zapisz jeden idealny zapis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres testów. Zdokumentuj zarówno optymalną ścieżkę działania, jak i ścieżkę przywracania do normalnego stanu. Próby ponownych działań, kontrolne punkty ludzkie oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później.
Rozpoczynanie pracy
W fazie Running It należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić dany krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy preferować małe, testowalne jednostki zamiast rozbudowanych skryptów. Gdy dany krok zawiedzie, powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowany proces. Konieczne jest ludzkie zatwierdzenie w przypadkach, gdy dochodzi do wydawania pieniędzy lub modyfikacji danych produkcyjnych. Połączenia realizowane w czasie kompilacji nie równają się kompletności biznesowej.
git clone https://github.com/kyndryl-cto/agentic-cortex.git
cp .env.example .env
# Fill in Azure OpenAI credentials
docker-compose up
curl -X POST http://localhost:8000/assess \
-H "Content-Type: application/json" \
-d '{"subscription_ids": ["sub-001"],
"tenant_id": "tenant-001"}'
{
"node": "evaluate_mesh", "status": "processing",
"agent": "mesh_evaluator", "timestamp": "..."
}
{
"node": "apply_policies", "status": "processing",
"agent": "policy_engine", "timestamp": "..."
}
Skalowanie do środowiska produkcyjnego: dodawanie domen bez ingerencji w proces
W fazie przechodzenia na środowisko produkcyjne należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanej punktacji kontrolnej, bez konieczności zgadywania ukrytego stanu. Traktuj tę fazę jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy artefaktom, zdefiniuj sprawdzenia sukcesu i odrzuć ciche, częściowe ukończenie zadania. Wymagaj ludzkiej aprobaty w przypadkach, gdy dochodzi do wydawania pieniędzy lub zmiany danych produkcyjnych. Połączenia realizowane w czasie kompilacji nie równają się pełności funkcjonalnej systemu.
Pisanie niestandardowych polityk Rego dla specyficznych wymogów zarządzania w organizacji
W fazie tworzenia niestandardowych zasad Rego należy określić dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Zapisuj czas trwania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy ścieżka przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Wprowadź ludzką aprobatę dla przypadków, w których wydawane są pieniądze lub zmieniane są dane produkcyjne. Podłączenia w czasie kompilacji nie równają się pełności funkcjonalności biznesowej. W fazie tworzenia niestandardowych zasad Rego należy określić dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Zdokumentuj zarówno ścieżkę prawidłowego działania, jak i ścieżkę naprawczą. Próby ponownych działań, ludzkie kontrolne punkty oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później.
sh.decision := result if {
"database" in lower(input.recommendation.resource_type)
_is_destructive_action(input.recommendation.title)
not _has_recovery_plan(input.recommendation.resource_id,
input.context)
result := {
"decision": "deny",
"reason": "Cannot decommission database without
verified recovery plan",
"rule_name": "protect_databases"
}
}
decision := result if {
input.recommendation.estimated_savings > 10000
result := {
"decision": "escalate",
"reason": sprintf("Projected savings $%.0f exceeds
threshold and requires approval",
[input.recommendation.estimated_savings]),
"rule_name": "high_impact_approval"
}
}
Wdrożenie pętli Sentinel z wykorzystaniem monitoringu chmurowego
Podczas przechodzenia przez etap wdrażania pętli Sentinel najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego awarii. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Wolno preferować małe, testowalne jednostki zamiast rozbudowanych skryptów. Gdy jakiś krok zawiedzie, awaria powinna wskazywać na konkretną odpowiedzialność, a nie na skomplikowany łańcuch operacji. Ustaw punkty kontrolne po kosztownych krokach. System powrotu nie powinien ponownie naliczać opłat za tę samą funkcję LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
Integracja pętli Sentinel z monitorowaniem chmurowym
Gdy pracujesz nad etapem Sentinel Loop i Cloud, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzuć możliwość cichego, częściowego ukończenia zadania. Ustaw punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji pracy nie powinno ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
Obserwowalność: Śledzenie pełnej ścieżki rozwiązania
Gdy przechodzisz przez etap Observability Tracing the Full, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zapisz czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy ścieżka przechodzi z wersji demonstracyjnej do środowisk współdzielonych. Ustal punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji nie powinno ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł. Gdy przechodzisz przez etap Observability Tracing the Full, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zdokumentuj zarówno ścieżkę prawidłowego działania, jak i ścieżkę naprawczą. Próby ponownych wywołań, mechanizmy ludzkiej kontroli oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dodawane później.
{
"decision_id": "pd-001",
"recommendation_id": "rec-001",
"policy_name": "protect_critical_resources",
"result": "deny",
"reason": "Policy prevents decommissioning
of critical resource",
"evaluated_at": "2026-03-12T14:23:01Z"
}
{
"conflict_id": "cf-001",
"resolution_strategy": "POLICY_OVERRIDE",
"resolved_by": "policy",
"resolution_outcome": "Resolved by policy:
'protect_critical_resources'
denied 'Decommission idle resource-x'"
}
Streszczenie architektury
Etap Streszczenia architektury działa najlepiej, gdy traktuje się go jako mierzalną powierzchnię. Zapisz jeden idealny przypadek działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian przed rozszerzaniem zakresu. Wolno preferować małe, testowalne jednostki zamiast rozbudowanych skryptów. Gdy jakiś krok zawiedzie, awaria powinna wskazywać na konkretną odpowiedzialność, a nie na skomplikowany łańcuch operacji. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wtórne struktury danych ukrywają informację o tym, który węzeł zapisał dane do którego pola, i powodują przerwanie kontynuacji po przerwach.
Lista kontrolna operacyjna
Dla etapu Listy kontrolnej operacyjnej zdefiniuj dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie wykonać dany krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu systemu.
Zachowaj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności przeglądania całej struktury.
Zastosuj zatwierdzenie przez człowieka do operacji, które powodują wydatki lub zmiany w danych produkcyjnych. Połączenia ustalane w czasie kompilacji nie gwarantują kompletności funkcjonowania systemu biznesowego.
Napisz krótki przewodnik: jak rotować klucze, jak opróżnić kolej z zadań, jak cofnąć ostatni proces importu.
Zdokumentuj zarówno standardowy przebieg działania, jak i ścieżkę odzyskiwania po awarii. Próby ponownych działań, kontrola przez człowieka oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dodawane później.
Zastosuj zatwierdzenie przez człowieka do operacji, które powodują wydatki lub zmiany w danych produkcyjnych. Połączenia ustalane w czasie kompilacji nie gwarantują kompletności funkcjonowania systemu biznesowego.
Zanim wdrożysz tę architekturę, zamroź wersje, utwórz dokładny zapis dla kluczowych etapów realizacji oraz potwierdź kroki odwracania zmian. Środowiska współdzielone wymagają ograniczeń szybkości, weryfikacji przynależności użytkowników oraz wyraźnego właściciela odpowiedzialnego za rotację haseł. Wolimy nudną niezawodność od pomysłowych, jednorazowych demonstracji.
Uwaga dotycząca zespołu 90ddb9951707: unikaj przechowywania kluczy dostawcy w repozytorium, ustaw ograniczenie liczby tokenów na sesję oraz przechowuj zapisy obok plików testowych, aby późniejsze zmiany modeli pozostawały porównywalne.