Nasazení a provoz

Nasazení Lazuria nemá jedinou podobu. V popsané verzi provozovatel spravuje lokální pracovní kopie a jednotlivé moduly. Nejdřív proto sestavte seznam zařízení, repozitářů, AI nástrojů, poskytovatelů modelů a připojených služeb. U každé položky určete, kdo ji spravuje.

Dostupné součásti a budoucí cíle

Následující stav odpovídá odkazované revizi zdrojů, ne automaticky nejnovější verzi produktu.

Součást	Stav	Co to znamená pro provoz
Zdrojová pracovní kopie s Gitem a Bunem	Dostupná	Provozovatel spravuje přístupy k repozitářům, závislosti a aktualizace.
Launchpad, Guide a Doctor	Dostupné	Lokální nástroje pro hledání a spouštění aplikací, návody a kontrolu instalace. Naslouchání na loopback adrese samo neověřuje identitu volajícího.
CLI v0	Experimentální	Používejte pevně určené verze a otestujte produkční automatizaci, která na CLI závisí.
Balíčkované CLI a generovaný root bez Gitu	Budoucí cíl	Nezahrnujte je do seznamu dnes nasazovaných součástí.
Dashboard, hostovaný workspace a Resident/Buddy	Volitelné, samostatně nasazované	U každé zapnuté služby evidujte vlastní identitu, síť, úložiště a provozovatele.

Součásti nasazení

1. Zařízení Principála: koncové zařízení, na kterém pracuje Kolega nebo AI Kolega.
2. Lokální root Lazuria: rozhraní a spouštěcí prostředí nad povolenými pracovními kopiemi Organizací.
3. Repozitář Organizace: hranice jedné firmy, její konfigurace a sdílené autoritativní podklady.
4. Workspace Moduly: aplikace s vlastními technickými podmínkami, závislostmi, kontrolami a cílem nasazení.
5. GitHub: systém identit a oprávnění pro repozitáře, Teamy, historii kontrol a vynucování pravidel větví v dokumentovaném výchozím modelu.
6. Klient a poskytovatel AI modelu: jejich výběr závisí na konkrétním nasazení a každý z nich má vlastní obchodní a datové podmínky.
7. Externí aplikace: jednotlivě povolené MCP servery, nástroje příkazové řádky nebo řízené postupy v prohlížeči s oprávněními u daného poskytovatele.

Ne každý modul musí běžet na veřejném serveru. Některé jsou lokální nástroje, jiné interní služby a další zpřístupňují veřejný web, například tuto dokumentaci. O způsobu provozu a návratu k předchozí verzi se rozhoduje pro každý modul samostatně.

Postup zavedení

1. Vymezte Organizaci

Určete organizaci v GitHubu, repozitáře, Teamy, administrátory a vlastníka procesu pro odebírání přístupů. Zároveň stanovte, která firemní data do Organizace patří a která jsou z ní výslovně vyloučená.

2. Stanovte minimální zabezpečení zařízení

Zdokumentujte vlastnictví zařízení, šifrování, aktualizace, dohled nad koncovými zařízeními, lokální zálohy, vzdálené smazání a reakci na incident. Rozumným výchozím bodem je jedna Organizace na zařízení. Více Organizací na jednom zařízení je vědomá výjimka uvnitř jedné domény důvěry, ne tvrdé oddělení tenantů. I zařízení vlastněné Principálem musí při práci s firemními daty splňovat pravidla Organizace. Přihlášení k poskytovatelům musí být samostatně pojmenovaná a odvolatelná.

3. Vyberte klienta a poskytovatele modelu

Zaznamenejte používaného klienta, poskytovatele modelu, typ účtu, způsob přihlášení, pravidla pro zpracování a uchovávání dat, telemetrii a smluvního vlastníka. Posouzení zopakujte při změně klienta, poskytovatele nebo typu účtu.

4. Povolte jen potřebné repozitáře a integrace

Začněte jedním jasně vymezeným scénářem. Principál má mít přístup pouze k repozitářům a rozsahům oprávnění, které pro něj potřebuje. Postupujte podle veřejného standardu pro externí aplikace a vyzkoušejte také odebrání přístupu.

5. Nastavte schvalování výsledků

Pro každý repozitář nastavte ochranu větví, povinné kontroly a review. U zpráv, infrastruktury, plateb, tajných údajů a nevratných operací pojmenujte skutečné oprávnění nebo potvrzení na straně poskytovatele. Pokud žádné neexistuje, uveďte, že schválení musí zajistit pracovní postup, nikoli software.

6. Proveďte přejímací testy

Ověřte běžný průběh úkolu, zamítnutý přístup k repozitáři, hranici přístupu klienta k lokálním souborům, odvolání přihlašovacího údaje, selhání CI, návrat k předchozí verzi, odebrání přístupů a eskalaci incidentu. Výsledky testů uložte spolu s rozhodnutím o nasazení.

Aktualizace a návrat k předchozí verzi

Zdrojové soubory Lazuria, konfigurace Organizace a jednotlivé moduly se verzují nezávisle. Aktualizace mají posouvat čisté primární pracovní kopie, projít deklarovanými kontrolami a vstoupit do produkce z přesně určeného zkontrolovaného commitu. Návrat k předchozí verzi se týká jen dotčeného repozitáře nebo nasazení; nesmí obnovit odvolané přihlašovací údaje ani zastaralá oprávnění.

Otázky, které musí zodpovědět provozovatel

• Kdo spravuje koncová zařízení, Teamy v GitHubu, závislosti a externí integrace?
• Který poskytovatel modelu a jaké podmínky účtu platí?
• Kde běží jednotlivé moduly a ze kterých sítí jsou dostupné?
• Jaké auditní záznamy vznikají, jak dlouho se uchovávají a kdo řeší incidenty?
• Jak se lokální data a přihlašovací údaje zálohují, mažou a obnovují?
• Které součásti jsou stabilní, experimentální, volitelné nebo zatím pouze plánované?
• Kdo poskytuje podporu a jaká doba reakce je případně smluvně přislíbená?

Odpovědi uložte k podkladům pro schválení nasazení. Pokud některá chybí, určete, kdo ji doplní, ještě před zahájením produkčního provozu.