Przejdź do treści głównej
FromNine
Menu

Inżynieria

Fundamenty chmurowe, dzięki którym wydania stają się rutyną.

Budujemy fundamenty chmurowe i wewnętrzne platformy deweloperskie, w których środowiska są kodem, wydania są podpisane i powtarzalne, a każdy wydatek ma właściciela.

Dla organizacji w Polsce, które utrzymują jeden fundament chmurowy dla kilku spółek, często z obowiązkami z ustawy o KSC lub z DORA.

Porozmawiajmy o projekcieArchitektura referencyjna
Chmura i inżynieria platform: warstwy kompetencjiCztery warstwy ułożone jedna za drugą. Od góry do dołu: obciążenia zespołów produktowych, wewnętrzna platforma deweloperska, podpisane potoki dostarczania oraz landing zone z tożsamością, siecią i politykami u podstawy.01Obciążenia zespołów produktowych02Wewnętrzna platforma deweloperska03Podpisane potoki dostarczania04Landing zone i polityki
  1. 01Landing zone z politykami zapisanymi jako kod i lokalizacją danych ustalaną dla każdego obciążenia
  2. 02Gotowe ścieżki (golden paths), które w powtarzalny sposób prowadzą nową usługę do produkcji
  3. 03SLO, przetestowane odtwarzanie i koszt każdego produktu widoczne dla osób, które decydują

01 Problemy

Oznaki, że fundament hamuje rozwój

  1. 01

    Każde środowisko jest inne

    Środowisko testowe i produkcyjne różnią się w sposób, którego nikt nie zapisał, a ręczne poprawki w konsoli znikają przy następnej przebudowie.

  2. 02

    Wydanie wymaga spotkania

    Wdrożenia są rzadkie, ręczne i planowane na wieczór. Zespoły łączą zmiany w paczki, przez co każde wydanie jest bardziej ryzykowne.

  3. 03

    Rachunek za chmurę zaskakuje wszystkich

    Koszty widać według subskrypcji, a nie według produktów. Moc GPU do prac nad AI rezerwuje ten, kto zapytał pierwszy.

  4. 04

    Nikt nie wie, czy odtwarzanie działa

    Kopie zapasowe istnieją. Odtwarzania nie przetestowano, a docelowego czasu odtworzenia i dopuszczalnej utraty danych nigdy nie uzgodniono z biznesem.

02 Co dostarczamy

Co dostarczamy

  1. 01 Landing zone i opcje suwerenności

    Landing zone to bazowe środowisko chmurowe: struktura kont i subskrypcji, tożsamość, sieć i reguły ochronne u dużych dostawców chmury i w europejskich ofertach chmury suwerennej, z politykami zapisanymi jako kod i lokalizacją danych dla każdego obciążenia.

    Co robimy

    • Projekt organizacji, grup zarządzania i kont
    • Sieć centralna, kontrola ruchu wychodzącego i prywatna łączność
    • Polityki jako kod dla lokalizacji danych, szyfrowania i tagowania
    • Odwzorowanie wymagań bezpieczeństwa, o które pytają zamawiający i organy nadzoru

    Co Państwo otrzymują

    • Landing zone zdefiniowana w całości w kodzie
    • Biblioteka polityk z procesem wyjątków
    • Analiza opcji suwerenności dla każdej klasy obciążeń

  2. 02 Infrastruktura jako kod i wewnętrzne platformy deweloperskie

    Terraform lub OpenTofu i Bicep dla infrastruktury, GitOps dla wdrożeń, Kubernetes lub usługi zarządzane tam, gdzie pasują, oraz gotowe ścieżki, dzięki którym zespół uruchamia zgodną usługę bez zgłoszeń do innych działów.

    Co robimy

    • Biblioteka modułów infrastruktury jako kodu
    • GitOps z promocją między środowiskami
    • Platforma Kubernetes lub zarządzane alternatywy
    • Szablony usług i portal deweloperski

    Co Państwo otrzymują

    • Wewnętrzna platforma deweloperska z gotowymi ścieżkami
    • Środowiska w modelu samoobsługi
    • Mapa drogowa platformy prowadzona przez zespół platformowy

  3. 03 Potoki dostarczania i bezpieczeństwo łańcucha dostaw

    Potoki, które budują raz, podpisują artefakty, zapisują ich pochodzenie zgodnie z SLSA, właściwie zarządzają sekretami i promują ten sam artefakt od testów do produkcji.

    Co robimy

    • Szablony potoków z bramkami jakości i bezpieczeństwa
    • Podpisywanie artefaktów i poświadczenie pochodzenia
    • Zarządzanie sekretami i rotacja kluczy
    • Reguły promocji i zapisy zmian

    Co Państwo otrzymują

    • Szablony potoków wielokrotnego użytku
    • Podpisane artefakty z weryfikowalnym pochodzeniem
    • Dowody wydań na potrzeby zarządzania zmianą

  4. 04 Obserwowalność i SRE

    Cele poziomu usług uzgodnione z biznesem, budżety błędów, które wyznaczają tempo wydań, OpenTelemetry w całym stosie i proces obsługi incydentów, który wspiera także obowiązki raportowe wynikające z ustawy o KSC i DORA tam, gdzie mają zastosowanie.

    Co robimy

    • Definiowanie SLO z właścicielami usług
    • Instrumentacja OpenTelemetry i pulpity
    • Alerty na objawy, a nie na przyczyny
    • Zarządzanie incydentami i przeglądy po incydentach

    Co Państwo otrzymują

    • Katalog SLO
    • Stos obserwowalności i pulpity
    • Procedury obsługi incydentów i raportowania

  5. 05 FinOps i moc obliczeniowa dla AI

    Przypisanie kosztów do produktów i zespołów, ekonomika jednostkowa, na przykład koszt jednej transakcji, oraz planowanie i kontrola kosztów mocy GPU dla obciążeń AI.

    Co robimy

    • Polityka tagowania i model alokacji kosztów
    • Koszty jednostkowe dla każdego produktu
    • Planowanie zobowiązań i rezerwacji
    • Harmonogramowanie GPU, limity i dobór rozmiaru

    Co Państwo otrzymują

    • Pulpity kosztów dla właścicieli produktów
    • Lista oszczędności z właścicielami
    • Plan mocy obliczeniowej dla AI

  6. 06 Odtwarzanie i wyjście

    Kopie zapasowe i odtwarzanie po awarii z jasno określonymi celami czasu odtworzenia (RTO) i punktu odtworzenia (RPO), testowane według harmonogramu, oraz strategia wyjścia oparta na prawie do zmiany dostawcy z aktu w sprawie danych (Data Act).

    Co robimy

    • RTO i RPO uzgodnione dla każdej usługi
    • Testy odtwarzania i przełączania awaryjnego
    • Mapa zależności usług krytycznych
    • Plan wyjścia i kontrole przenoszalności danych

    Co Państwo otrzymują

    • Przetestowane procedury odtwarzania
    • Raporty z testów odtwarzania
    • Udokumentowana strategia wyjścia

03 Architektura

Poglądowa architektura referencyjna

Kod wchodzi z lewej strony, a działające obciążenia wychodzą z prawej. Pomiędzy nimi potok podpisuje to, co buduje, rejestr przechowuje tylko podpisane artefakty, a kontroler GitOps promuje je między środowiskami zgodnie z politykami.

Pod spodem znajduje się landing zone: struktura organizacji, tożsamość, sieć, klucze, odtwarzanie i kontrola kosztów, zdefiniowane raz w kodzie i wspólne dla wszystkich zespołów produktowych.

Warstwy na rysunku

Dostarczanie
Repozytoria, potoki, podpisane artefakty i promocja GitOps.
Platforma
Platforma deweloperska, polityki jako kod i środowisko uruchomieniowe, do którego wdrażają zespoły produktowe.
Landing zone
Organizacja, tożsamość, sieć, klucze, odtwarzanie i kontrola kosztów FinOps.
Utrzymanie
Telemetria, SLO, budżety błędów i reagowanie na incydenty w całym środowisku.
Przykład poglądowy

  1. Dostarczanie

    • Repozytoria kodu i IaC
    • Budowa, podpis, poświadczenie
    • Rejestr podpisanych artefaktów
    • Promocja GitOps

  2. Platforma

    • Platforma deweloperska i gotowe ścieżki
    • Polityki jako kod
    • Kubernetes i usługi zarządzane
    • Obciążenia zespołów produktowych

  3. Landing zone

    • Struktura zarządzania
    • Tożsamość i dostęp
    • Węzeł sieci i ruch wychodzący
    • Klucze i sekrety
    • Kopie zapasowe i odtwarzanie
    • Alokacja kosztów

  4. Utrzymanie

    • OpenTelemetry, SLO i budżety błędów, reagowanie na incydenty
Podpisane dostarczanie na landing zone z politykami

Architektura poglądowa, nie system klienta.

Diagram w formie tekstu

Główna ścieżka prowadzi od repozytoriów kodu i infrastruktury przez potoki, które budują, podpisują i poświadczają, do rejestru artefaktów, następnie do kontrolera GitOps i na końcu do obciążeń zespołów produktowych.

Wewnętrzna platforma deweloperska udostępnia gotowe ścieżki do potoków. Polityki jako kod ograniczają kontroler GitOps. Platforma uruchomieniowa z Kubernetes i usługami zarządzanymi utrzymuje obciążenia. Klucze zarządzane przez klienta zasilają warstwę polityk.

Landing zone poniżej obejmuje strukturę zarządzania, tożsamość i dostęp, centralny węzeł sieci, klucze, kopie zapasowe i odtwarzanie oraz kontrolę kosztów FinOps. Obserwowalność z SLO i reagowaniem na incydenty obejmuje całą platformę.

04 Uwarunkowania i ograniczenia

Uwarunkowania inżynierskie i ograniczenia

  • Suwerenność ma wiele stopni

    Jak do tego podchodzimy

    Klasyfikujemy obciążenia według wrażliwości i dopasowujemy każdą klasę do opcji: regiony UE dużego dostawcy chmury, oferta chmury suwerennej albo infrastruktura prywatna. Kompromisy dotyczące funkcji, kosztów i utrzymania zapisujemy.

    Ograniczenia i zależności

    Oferty chmury suwerennej często mają mniej usług zarządzanych, w tym usług AI. Niektóre obciążenia będą tam droższe lub uboższe w funkcje, a to jest decyzja biznesowa.

  • Platforma potrzebuje właściciela produktu

    Jak do tego podchodzimy

    Wewnętrzną platformę traktujemy jak produkt z użytkownikami, mapą drogową i pętlami informacji zwrotnej oraz pomagamy zbudować zespół, który ją prowadzi.

    Ograniczenia i zależności

    Platforma bez zespołu staje się wąskim gardłem. Jeśli organizacja nie może jej obsadzić, zalecimy usługi zarządzane i mniej warstw abstrakcji.

  • Przepisy kształtują utrzymanie

    Jak do tego podchodzimy

    Klasyfikacja incydentów, terminy zgłoszeń i zbieranie dowodów są wbudowane w proces obsługi incydentów tam, gdzie organizację obejmuje ustawa o KSC lub DORA.

    Ograniczenia i zależności

    Ustalenie, czy organizacja jest podmiotem kluczowym lub ważnym i jakie obowiązki z tego wynikają, pozostaje zadaniem jej zespołów ds. zgodności i doradców prawnych.

  • Kontrola kosztów to wspólne zadanie

    Jak do tego podchodzimy

    Pokazujemy koszt każdego produktu i dodajemy reguły ochronne, takie jak budżety, limity i planowane wyłączanie nieużywanych środowisk.

    Ograniczenia i zależności

    Największe oszczędności zwykle dają decyzje architektoniczne i decyzje o sposobie użycia, które podejmują właściciele produktów, a nie sama platforma.

05 Jak pracujemy

Jak pracujemy

Najpierw fundamenty, potem jeden zespół na gotowej ścieżce, a potem wszyscy pozostali.

  1. 01

    Ocena i klasyfikacja

    Obciążenia, wrażliwość danych, obecne koszty i kontrole, których oczekują audytorzy.

    RezultatKlasyfikacja obciążeń i opcje docelowe

  2. 02

    Budowa landing zone

    Wszystko jako kod, przeglądane z działem bezpieczeństwa, z procesem obsługi wyjątków.

    RezultatLanding zone w produkcji

  3. 03

    Zespół pilotażowy

    Jeden zespół produktowy przechodzi na gotową ścieżkę, a jego trudności kształtują platformę.

    RezultatPierwsza usługa na platformie

  4. 04

    Skalowanie i przekazanie

    Dołączają kolejne zespoły, zespół platformowy przejmuje odpowiedzialność, a odtwarzanie jest testowane według harmonogramu.

    RezultatMapa drogowa platformy i raporty z testów odtwarzania

06 Kontrola człowieka

Gdzie kontrolę zachowuje człowiek

Platformę prowadzi automatyzacja. Decyzje, które niosą ryzyko lub koszt, należą do ludzi.

  • Zmiany w produkcji są identyfikowalne

    Każda zmiana w produkcji pochodzi z przejrzanego commita, więc zawsze wiadomo, kto co zmienił i kto to zatwierdził.

  • Dostęp awaryjny jest rzadki i rejestrowany

    Dostęp awaryjny jest ograniczony w czasie, wymaga uzasadnienia i jest później sprawdzany.

  • Wyjątki od polityk mają właściciela

    Gdy obciążenie wymaga wyjątku od reguły ochronnej, zatwierdza go wskazany właściciel ryzyka, z datą wygaśnięcia.

  • Cele ustalają właściciele usług

    Cele odtwarzania i poziomy usług są uzgadniane z właścicielem biznesowym każdej usługi, a nie ustalane przez sam zespół platformowy.

07 Technologie

Technologie, z którymi pracujemy

Chmura
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Europejskie oferty chmury suwerennej
Infrastruktura i dostarczanie
  • Terraform i OpenTofu
  • Bicep
  • Argo CD i Flux
  • GitHub Actions, GitLab CI i Azure DevOps
Środowisko uruchomieniowe
  • Kubernetes i jego warianty zarządzane
  • Platformy serverless i kontenerowe
  • Service mesh tam, gdzie się opłaca
  • Pule węzłów GPU dla obciążeń AI
Utrzymanie
  • OpenTelemetry
  • Prometheus i Grafana
  • Monitorowanie natywne dla chmury
  • Silniki polityk, takie jak OPA

Wymienienie technologii opisuje nasze doświadczenie inżynierskie. Nie oznacza partnerstwa z jej dostawcą ani jego rekomendacji.

08 Przykład

Przykład poglądowy

Przykład poglądowy

Wspólna landing zone dla komunalnej grupy ciepłowniczej i wodociągowej

01Sytuacja
Przedsiębiorstwo ciepłownicze i spółka wodociągowa z jednej grupy komunalnej utrzymują osobne środowiska chmurowe z różnymi zabezpieczeniami, a raportowanie z systemów SCADA działa na starzejących się serwerach. Obie spółki przygotowują się do obowiązków z ustawy o KSC i nikt nie potrafi pokazać stanu bezpieczeństwa grupy w jednym widoku.
02Co byśmy zbudowali
Jedna landing zone w kodzie z zestawami polityk dla każdej spółki, wspólnym logowaniem i procesem obsługi incydentów, który klasyfikuje zdarzenia i kieruje zgłoszenia osobno dla każdej spółki.
03Gdzie decyduje człowiek
Osoba odpowiedzialna za cyberbezpieczeństwo w każdej spółce zatwierdza wyjątki od polityk dla swoich obciążeń, a zespół bezpieczeństwa grupy odpowiada za wspólny poziom bazowy.
04Co byśmy mierzyli
Czas od wykrycia incydentu do jego klasyfikacji, odsetek obciążeń objętych politykami i liczba zaliczonych testów odtwarzania w kwartale.

09 Perspektywa branżowa

W Państwa branży

  • Administracja publiczna

    Opcje suwerenności dla każdej klasy danych, wymagania bezpieczeństwa zamawiających i plany wyjścia, które przetrwają kolejne postępowanie o udzielenie zamówienia.

  • Usługi finansowe

    Operacyjna odporność cyfrowa zgodnie z DORA: przetestowane odtwarzanie, nadzór nad zewnętrznymi dostawcami usług ICT i raportowanie incydentów wbudowane w codzienne utrzymanie.

Polska

Dowody przygotowane raz, dla każdego nadzoru

Dyrektywę NIS2 wdraża w Polsce ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252), obowiązująca od 3 kwietnia 2026 r. Wykaz podmiotów kluczowych i ważnych prowadzony jest od 13 kwietnia 2026 r., a samodzielna rejestracja trwała od 7 maja do 3 października 2026 r.

Podmioty finansowe stosują dodatkowo rozporządzenie DORA, stosowane od 17 stycznia 2025 r., z własnym raportowaniem incydentów i nadzorem nad zewnętrznymi dostawcami usług ICT. Komisja Nadzoru Finansowego (KNF) jest w Polsce właściwym organem w rozumieniu art. 46 rozporządzenia DORA.

Projektujemy landing zone, w których lokalizacja danych, logowanie i klasyfikacja incydentów są politykami, a nie osobnymi projektami, więc nową spółkę włącza się przez konfigurację. Plany wyjścia opierają się na prawie do zmiany dostawcy z aktu w sprawie danych (Data Act) i są testowane, a nie tylko spisane.

Pytania o chmurę i inżynierię platform

Którego dostawcę chmury poleca FromNine?

Tego, który pasuje do obciążeń, istniejących umów i wymagań dotyczących suwerenności. Pracujemy z dużymi dostawcami chmury i z europejskimi ofertami chmury suwerennej, a kompromisy dokumentujemy tak, aby wybór dało się obronić w postępowaniu o udzielenie zamówienia i później zweryfikować.

Czy potrzebujemy Kubernetes?

Nie zawsze. Kubernetes opłaca się przy wielu usługach i zespole, który utrzymuje platformę. Przy kilku usługach zarządzane platformy kontenerowe lub serverless są często prostsze i tańsze w utrzymaniu.

Jak wygląda podejście do bezpieczeństwa?

Bezpieczeństwo jest wbudowane w landing zone i potoki: tożsamość z minimalnymi uprawnieniami, polityki jako kod, podpisane artefakty i sekrety, które nigdy nie trafiają do kodu. FromNine ma certyfikat ISO/IEC 27001 dla systemu zarządzania bezpieczeństwem informacji.

Czy da się obniżyć nasze koszty chmury?

Zwykle tak, ale nie obiecujemy konkretnego procentu, zanim zobaczymy dane. Zaczynamy od pokazania kosztu każdego produktu, a potem realizujemy listę oszczędności z właścicielami, którzy mogą działać.

Jak uniknąć uzależnienia od dostawcy?

Przez świadomy wybór miejsc, w których korzysta się z usług specyficznych dla dostawcy, utrzymywanie infrastruktury w kodzie oraz udokumentowany i przetestowany plan wyjścia. Akt w sprawie danych (Data Act) wzmacnia prawo do zmiany dostawcy, a plan wyjścia pozwala z niego realnie skorzystać.

Trzy najbliższe wydania jako punkt wyjścia

Wskażemy, co sprawi, że staną się rutyną, oraz ile będzie kosztować zbudowanie i utrzymanie takiego fundamentu.

Porozmawiajmy o projekcieArchitektura i doradztwo