Usługi / Wsparcie software house
Dla agencji i software house’ówPlatforma per klient, bez budowania własnego opsu
GitLab albo GitHub Actions na delivery. Argo CD na środowiska klientów. Kubernetes z izolacją. Grafana i dyżur poza godzinami biura. Wy dostarczacie produkt, my warstwę, którą da się wpisać w umowę z klientem.
Delivery, tenanci, dyżur
Software house bez platformy powtarza ten sam ops przy każdym kliencie. Składamy CI, GitOps, izolację i obserwowalność w warstwę, którą sprzedajecie obok produktu.
- Nie wchodzimy w Wasz backlog produktowy. Trzymamy infrastrukturę pod nim.
- Model retainer albo per projekt, z jasnym podziałem, kto bierze P1 aplikacji.
Szablon pipeline, który zespół kopiuje na nowy projekt
Jeden harness: test, skan, obraz, preview. Nowy klient nie zaczyna od pustego YAML. Runner i registry są Wasze albo nasze, z izolacją i kosztem per projekt.
Szablon
Repo starter, environments, sekrety, polityka branchy.
Preview
MR wstaje na izolowanej przestrzeni i znika. Klient widzi build, nie Wasz laptop.
Skan
Zależności i obraz w pipeline. Znalezisko idzie do backlogu projektu.
Billing
Minuty CI i registry da się przypisać do klienta.
Gdy zespół żyje na GitHubie, ops nie wymaga migracji
Ten sam poziom bramek i OIDC do chmury. Workflow per szablon. Actions na kubernetes/kubernetes to wzorzec skali, u Was schodzimy do tego, co zespół utrzyma.
OIDC
Bez długowiecznego klucza w secrets. Rola per środowisko.
Macierz
Klient A nie widzi sekretów klienta B. Osobne environment protections.
Cache
Szybszy build bez wycieku artefaktów między tenantami.
Ślad
Kto zatwierdził deploy na produkcję klienta.
Środowisko per klient, z osobnym projektem
ApplicationSet albo szablon projektu. Namespace, quota, sieć. Klient nie siedzi na wspólnym cluster-admin. Sync i health widać bez wchodzenia na Wasz Slack o 23.
Izolacja
RBAC, NetworkPolicy, osobne sekrety. Blast radius jednego projektu.
Szablon
Nowe środowisko z merge, nie z weekendową sesją kubectl.
Promocja
Stage klienta, potem produkcja. Ta sama ścieżka co u Was w środku.
Offboarding
Retencja danych i kasowanie namespace są w liście kontrolnej umowy.
Dyżur i SLO, które da się sprzedać
Dashboard per tenant albo folder. Alert idzie do nas, z eskalacją do Was gdy aplikacja. Raport dostępności do umowy. Nie budujecie nocnej zmiany od zera.
SLO
p95 i błąd per usługa klienta. Budżet zapisany.
Dyżur
P1 na infrastrukturę. P2 na aplikację według umowy.
Koszt
Showback per projekt. Klient widzi, za co płaci w chmurze.
Handover
Gdy projekt schodzi, dokumentacja i IaC zostają, nie lore w głowie.
Od szablonu do opieki nad tenantem
Najpierw Wasz sposób delivery. Potem katalog środowisk. Na końcu dyżur i showback.
- Szablon Pipeline, chart, sekrety, sieć, quota.
- Onboarding Pierwszy klient na szablonie, izolacja, billing.
- Rytm Upgrade platformy, skan, przegląd tenanta.
- Umowa SLA, eskalacja, offboarding, raport.
Omówimy szablon środowisk i SLA
Na tej podstawie przygotujemy warstwę platformy pod Wasze delivery.
Skontaktuj się