Platform Engineering 101: wychodzenie poza tradycyjne systemy zgłoszeń w Azure

By Mirko Peters · 2026-08-13

Automatically translated with AI from the original post. Read the English original

Titelbild: Platform Engineering 101: Moving Beyond Traditional Ticketing Systems in Azure

Witamy ponownie, słuchacze i czytelnicy, w kolejnym dogłębnym omówieniu ewoluującego świata architektury chmury, doświadczenia deweloperów i nowoczesnego DevOps. Jeśli słuchaliście naszego najnowszego odcinka podcastu, wiecie, że spędziliśmy sporo czasu na demontażu jednego z najbardziej frustrujących wąskich gardeł w nowoczesnym dostarczaniu oprogramowania: tradycyjnego systemu zgłoszeń IT. Znacie ten schemat. Deweloper potrzebuje nowej bazy danych, środowiska testowego albo prostej zmiany DNS. Otwiera zgłoszenie. Zgłoszenie czeka w kolejce. Zostaje przeanalizowane, przypisane, przypisane ponownie, a w końcu, po dniach, a nawet tygodniach, wykonywane są ręczne czynności operacyjne. Zanim infrastruktura zostanie udostępniona, sprint już się skończył, rozpęd minął, a wszyscy są wyczerpani.

W tym towarzyszącym wpisie na blogu mocno rozwiniemy kluczowe koncepcje, o których rozmawialiśmy na antenie. Przyjrzymy się, jak organizacje korzystające z Microsoft Azure mogą wyrwać się z tej wyniszczającej pętli ręcznych czynności, przyjmując transformacyjną dyscyplinę Platform Engineering i budując solidne wewnętrzne platformy dla deweloperów (IDP).

Wprowadzenie: wąskie gardło tradycyjnego zgłaszania w Azure

Wyobraźmy sobie znany obraz. Twoja organizacja przeniosła swoje obciążenia do Microsoft Azure. Przyjęliście chmurę, korzystacie z Azure Kubernetes Service (AKS), Azure SQL, Cosmos DB i App Services. Na papierze jesteście nowocześni. Jeśli jednak przyjrzeć się uważnie waszemu procesowi, deweloperzy traktują Azure tak samo, jak kiedyś traktowali serwerownię on-premises: przez mur biurokracji i kolejki zgłoszeń.

Ilekroć zespół chce udostępnić zasób, nie może zrobić tego samodzielnie. Zabezpieczenia zostały wdrożone jako przeszkody zamiast chodników. Zespoły składają zgłoszenie do centralnego zespołu platformy lub operacji. Powoduje to ogromne obciążenie poznawcze i całkowicie podważa zwinność, którą miała zapewnić chmura obliczeniowa. Azure oferuje niesamowitą szybkość i programowalną kontrolę, a mimo to deweloperzy są często od niej odcięci. Tradycyjny system zgłoszeń działa jak podatek od innowacji. Każde żądanie wymaga interwencji człowieka, co wprowadza błędy ludzkie, nieporozumienia i dotkliwe opóźnienia. Musimy przestać traktować deweloperów jak dzieci, którym nie można powierzyć infrastruktury, i zacząć traktować ich jak wzmocnionych twórców, którzy potrzebują samoobsługi opartej na zautomatyzowanych zabezpieczeniach.

Czym jest Platform Engineering i dlaczego ma znaczenie?

Jak więc to naprawić? Oto Platform Engineering. W ostatnich latach Platform Engineering wyłonił się jako ostateczna ewolucja DevOps. O ile DevOps w teorii zburzył mur między developmentem a operacjami, o tyle w praktyce wiele organizacji po prostu zrzuciło cały ciężar operacyjny na deweloperów. Od nagle oczekiwano, że deweloperzy będą ekspertami od Kubernetes, Terraform, bezpieczeństwa sieci i zasad IAM w Azure, jednocześnie próbując pisać logikę biznesową.

Platform Engineering uznaje, że taki stan jest nie do utrzymania. Zamiast zmuszać deweloperów do zostania ekspertami od infrastruktury albo do czekania w kolejce zgłoszeń, Platform Engineering traktuje doświadczenie deweloperskie jako produkt. Dedykowany zespół platformy buduje wewnętrzną platformę dla deweloperów (IDP), która ukrywa podstawową złożoność Azure.

Dlaczego to ma znaczenie? Ponieważ obciążenie poznawcze jest cichym zabójcą produktywności inżynierskiej. Gdy deweloperzy spędzają 40 procent czasu na zmaganiu się z konfiguracjami infrastruktury, listami kontrolnymi zgodności i czekaniem na zatwierdzenia, nie tworzą funkcji, które zachwycają klientów. Platform Engineering ma znaczenie, ponieważ przywraca zespołom inżynierskim stan przepływu. Dostarcza złote ścieżki, czyli wstępnie zatwierdzone, wysoce bezpieczne, zgodne architektury, które deweloperzy mogą uruchomić jednym kliknięciem lub poleceniem.

Od ręcznych operacji dalej: wizja wewnętrznych platform dla deweloperów

Aby naprawdę wyjść poza ręczne operacje w Azure, musimy zmienić sposób myślenia z zarządzania infrastrukturą na budowanie platform. Wewnętrzna platforma dla deweloperów to nie tylko pojedyncze narzędzie; to spójna warstwa umieszczona na infrastrukturze chmury Azure, która kuruje usługi i narzędzia, aby dostarczać oprogramowanie bez tarcia.

Problem z doraźnymi skryptami i chaotycznym udostępnianiem zasobów

Niektóre organizacje zauważają, że obsługa zgłoszeń jest powolna, więc przyznają deweloperom uprawnienia współautora do subskrypcji Azure i pozwalają im uruchamiać, co tylko zechcą. To przeciwny skrajny biegun, który jest równie katastrofalny. Wkrótce mamy nienadzorowane zasoby, gwałtownie rosnące rachunki za chmurę, poważne luki w zabezpieczeniach i brak standardowego sposobu monitorowania czy aktualizowania czegokolwiek. To dziki zachód.

Idealny punkt równowagi w IDP

IDP zapewnia idealną równowagę. Oferuje możliwości samoobsługi, jednocześnie wbudowując bezpieczeństwo, zgodność, zarządzanie kosztami i standardy architektury bezpośrednio w przepływ pracy. Deweloperzy zyskują autonomię, której pragną, a zespoły operacyjne i bezpieczeństwa otrzymują zarządzanie i zgodność, których wymagają. To scenariusz win-win umożliwiony przez automatyzację.

Kluczowe filary budowy platformy deweloperskiej opartej na Azure

Budując wewnętrzną platformę deweloperską (Internal Developer Platform) w Microsoft Azure, musisz oprzeć się na solidnych podstawach architektonicznych. Przyjrzyjmy się kluczowym filarom, które decydują o sukcesie platformy opartej na Azure.

1. Infrastruktura jako kod (IaC) i katalogi modułów

Sercem każdej platformy chmurowej jest infrastruktura jako kod. W ekosystemie Azure oznacza to zwykle Terraform, Bicep lub szablony Azure Resource Manager (ARM). Samo pisanie plików Bicep to jednak za mało. Zespół platformy musi stworzyć wyselekcjonowany katalog modułowych, wielokrotnego użytku i bezpiecznych szablonów. Na przykład zamiast pozwalać deweloperowi pisać własną konfigurację bazy danych od podstaw, platforma udostępnia moduł Azure SQL, który już zawiera szyfrowanie klasy korporacyjnej, właściwą integrację z siecią oraz wstępnie skonfigurowane zasady kopii zapasowych. Deweloper podaje jedynie nazwę aplikacji i poziom.

2. Zasady jako kod z Azure Policy

Zarządzanie ładem nie może opierać się na ludziach odhaczających pola. Musi być zautomatyzowane. Integrując Azure Policy i Azure Blueprints z platformą, zapewniasz, że każdy zasób udostępniany przez IDP automatycznie spełnia wymogi ram regulacyjnych oraz wewnętrznych standardów firmy. Jeśli deweloper spróbuje utworzyć konto magazynu bez szyfrowania w tranzycie, platforma natychmiast to wychwyci i odrzuci żądanie, zanim w ogóle dotrze ono do Azure.

3. Płynna integracja CI/CD i GitOps

Twoje IDP nie może funkcjonować w próżni. Musi integrować się natywnie z systemem kontroli wersji i potokami wdrożeniowymi. Niezależnie od tego, czy używasz GitHub Actions, Azure DevOps czy ArgoCD do GitOps, platforma powinna bezproblemowo orkiestrować potok od zatwierdzenia kodu do wdrożenia w Azure. Deweloperzy powinni móc uruchamiać lub zamykać środowiska bezpośrednio z poziomu swoich pull requestów.

4. Zunifikowana obserwowalność i monitorowanie

Nie da się zarządzać tym, czego nie da się zmierzyć. Dobra platforma zapewnia obserwowalność od razu po wdrożeniu, podłączając aplikacje bezpośrednio do Azure Monitor, Application Insights i Azure Log Analytics. Gdy deweloper uruchamia nowy mikroserwis przez platformę, logowanie, metryki i śledzenie są automatycznie konfigurowane i połączone bez ręcznej instrumentacji.

Przyspieszanie harmonogramów dostaw i ograniczanie tarć dla deweloperów

Porozmawiajmy o realnym wpływie wdrożenia tej architektury. Gdy dwutygodniowy proces obsługi zgłoszeń zastąpisz dwuminutowym portalem samoobsługowym, wskaźniki zmieniają się diametralnie.

Czas wprowadzenia na rynek i częstotliwość wdrożeń

Tempo rozwoju gwałtownie rośnie. Funkcje, które kiedyś utykały w środowiskach przejściowych, czekając na ręczną konfigurację sieci, mogą być teraz wdrażane natychmiast. Zespoły mogą tworzyć efemeryczne środowiska dla każdego pull requesta, testować kod w środowisku będącym dokładną repliką produkcji, a po scaleniu PR-a je usuwać. Takiego poziomu zwinności nie da się osiągnąć w ręcznym świecie zgłoszeń.

Eliminowanie wypalenia deweloperów

Satysfakcja deweloperów to kluczowy wskaźnik, który zbyt wiele organizacji ignoruje. Ciągła walka z biurokracją, czekanie na inne zespoły i zmaganie się z powtarzalnymi, mało wartościowymi zadaniami bezpośrednio prowadzą do wypalenia zawodowego i wysokiej rotacji. Usuwając tarcia i automatyzując żmudne czynności, tworzysz środowisko, w którym inżynierowie czują się kreatywni, produktywni i docenieni. Szczęśliwi deweloperzy piszą lepszy kod.

Najlepsze praktyki wdrażania inżynierii platformy w organizacji

Budowa wewnętrznej platformy deweloperskiej w Azure brzmi świetnie, ale jak ją faktycznie zrealizować bez poważnych zakłóceń? Oto kilka najlepszych praktyk, które rekomendujemy naszym słuchaczom i klientom konsultingowym.

Traktuj platformę jak produkt

To fundamentalna zasada platform engineering. Twoi wewnętrzni deweloperzy są Twoimi klientami. Musisz prowadzić badania użytkowników, zbierać opinie, pisać dokumentację i stale ulepszać platformę na podstawie ich potrzeb. Jeśli platforma jest toporna i trudna w obsłudze, deweloperzy znajdą obejścia, a Twoja inicjatywa poniesie porażkę.

Zacznij od małego: minimalnie użyteczna platforma (MVP)

Nie próbuj budować od pierwszego dnia monolitycznej platformy, która obejmie wszystko. Zacznij od jednego przypadku użycia, który rozwiązuje poważny problem. Na przykład zacznij od automatyzacji udostępniania standardowych mikrousług w usłudze Azure Kubernetes Service z wbudowanym logowaniem i bazami danych. Gdy to się sprawdzi i zostanie przyjęte przez zespoły, rozszerzaj możliwości platformy iteracyjnie.

Duży nacisk na dokumentację dla deweloperów i doświadczenie w portalu

Nawet najpotężniejsza automatyzacja po stronie zaplecza jest bezużyteczna, jeśli deweloperzy nie wiedzą, jak z niej korzystać. Zainwestuj w portal deweloperski. Narzędzia takie jak Backstage od Spotify zyskały ogromną popularność właśnie w tym celu. Połącz Backstage z integracjami Azure, a Twoje zespoły otrzymają jeden punkt dostępu, z którego mogą przeglądać dokumentację, eksplorować katalogi usług i uruchamiać działania samoobsługowe.

Podsumowanie: wspieranie nowoczesnych zespołów deweloperskich na przyszłość

Tradycyjne systemy zgłoszeń to relikty minionej epoki. Spowalniają innowacje, frustrują inżynierów i nie wykorzystują prawdziwej mocy oraz zwinności infrastruktury chmurowej, takiej jak Microsoft Azure. Przyjmując Platform Engineering i budując przemyślane, bezpieczne i zautomatyzowane wewnętrzne platformy deweloperskie (Internal Developer Platforms), organizacje mogą wyeliminować wąskie gardła, egzekwować solidne zarządzanie i uwolnić pełen potencjał swoich zespołów deweloperskich.

Pamiętaj, że celem nowoczesnej architektury chmurowej nie jest po prostu przeniesienie serwerów do cudzego centrum danych. Chodzi o to, by wzmocnić Twoich ludzi, aby dostarczali wartość szybciej i bezpieczniej niż kiedykolwiek wcześniej. Dziękujemy za poświęcony czas na lekturę tego rozszerzonego wpisu na blogu. Koniecznie zasubskrybuj podcast, udostępnij ten artykuł swoim zespołom platformowym i DevOps, a do zobaczenia w kolejnym odcinku, gdy będziemy dalej odkrywać najnowsze osiągnięcia w technologiach chmurowych!