Dlaczego brak produkcji nie jest wyrokiem dla juniora w chmurze
Celem osoby na poziomie juniora w chmurze jest zbudowanie realnego, powtarzalnego doświadczenia z AWS, Azure lub GCP tak, by dało się o nim sensownie opowiadać na rozmowie, pokazać w portfolio i podeprzeć konkretnym kodem. Dostęp do prawdziwej produkcji to wygodny skrót, ale nie warunek konieczny.
Doświadczenie komercyjne vs doświadczenie realne
W cloudzie często miesza się dwa pojęcia: „doświadczenie komercyjne” i „doświadczenie realne”. Komercyjne oznacza, że ktoś ci za to płacił. Realne – że faktycznie zbudowałeś, wdrożyłeś i utrzymywałeś coś, co działa w chmurze, ma użytkowników (choćby kilku) i da się to odtworzyć.
Rekruter i tech lead, patrząc na juniora, przede wszystkim szukają odpowiedzi na pytania:
Czy potrafisz skonfigurować podstawowe zasoby w chmurze: sieć, compute, storage, IAM?
Czy rozumiesz, jak one się łączą w prostą architekturę (np. API + baza danych + S3/Blob Storage)?
Czy masz doświadczenie z automatyzacją (Infrastructure as Code, proste CI/CD)?
Czy potrafisz debugować problemy i czytasz logi, a nie tylko klikasz na chybił trafił?
Na te pytania można odpowiedzieć twierdząco, nie mając ani jednego dnia na produkcji, jeśli zbudujesz świadomie swoje „środowisko produkcyjne na niby” i potraktujesz je jak prawdziwe. Pracodawca nie jest w stanie zawsze sprawdzić, czy serwis, który pokazujesz, zarabiał miliony – ale bardzo szybko wyczuje, czy wiesz, o czym mówisz.
Jak myślą rekruterzy i tech leadzi przy zatrudnianiu juniora cloud
Doświadczony inżynier, który rekrutuje juniora do zespołu cloud/DevOps, ma na ogół kilka prostych kryteriów:
Umiesz uczyć się w locie – bo chmura zmienia się szybciej niż jakakolwiek technologia on-prem.
Ogarniesz podstawy samodzielnie – nie trzeba cię prowadzić za rękę przy każdej drobnostce.
Masz zdrowy respekt do produkcji – nie usuniesz przypadkiem całej VPC, bo „kliknąłeś nie tam, gdzie trzeba”.
Rozumiesz koszty i bezpieczeństwo na podstawowym poziomie.
Słowo „production” w CV jest miłe, ale jeśli na rozmowie nie potrafisz wyjaśnić, co konkretnie robiłeś, co zepsułeś i jak naprawiłeś, to ten napis nic nie znaczy. Z kolei kandydat, który mówi:
„Od roku utrzymuję swój projekt w AWS: API Gateway + Lambda + RDS. Mam trzy środowiska, deploy przez GitHub Actions, logowanie w CloudWatch, alerty na błędy 5xx i backupy bazy. Co miesiąc robię test odtworzenia backupu.”
– brzmi jak ktoś, kogo można spokojnie wpuścić na prawdziwą produkcję, nawet jeśli jego system obsługuje 10 znajomych zamiast 10 tysięcy użytkowników.
Sandbox bez stresu vs produkcja z paraliżem
Paradoksalnie, nauka na produkcji bywa gorsza niż nauka w dobrze zrobionym sandboxie. W realnym projekcie komercyjnym junior często:
ma ograniczone uprawnienia, więc nie dotyka sieci, IAM ani poważniejszych usług,
robi głównie manualne zadania, bo seniorzy boją się dać mu coś, co może zepsuć system,
żyje w ciągłym strachu przed zepsuciem czegoś – co zabija eksperymentowanie, a bez eksperymentów w chmurze daleko się nie zajdzie.
W prywatnym środowisku sandboxowym możesz:
tworzyć i kasować VPC, IAM role, pipeline’y CI/CD tyle razy, ile chcesz,
testować różne topologie sieci, polityki bezpieczeństwa, ustawienia autoscalingów,
świadomie psuć rzeczy, a potem je odtwarzać, ucząc się sposobu myślenia produkcyjnego bez realnego ryzyka dla klientów.
To doświadczenie, choć niekomercyjne, jest bardzo realne. Jeśli je dobrze udokumentujesz (kody w repo, diagramy, krótkie opisy incydentów), zyskujesz coś, co wielu „juniorów z produkcji” w ogóle nie ma – przekrojowe zrozumienie chmury.
Kiedy wczesny dostęp do produkcji bardziej szkodzi niż pomaga
Popularne marzenie: „dostanę dostęp do produkcji jak najszybciej, to będę się szybciej uczyć”. Rzeczywistość bywa inna. Zbyt wczesny dostęp do produkcji może oznaczać:
toksyczny stres – każda zmiana to obawa o incydent i „blame”,
naukę złych nawyków – szybkie klikanie w konsoli bez IaC, brak dokumentacji, brak rollbacków,
brak czasu na zrozumienie decyzji architektonicznych – tylko „łatanie” i gaszenie pożarów.
Dobry scenariusz dla juniora to: najpierw mocny sandbox, który traktujesz jak produkcję, a dopiero potem prawdziwa produkcja w firmie. Wtedy nie uczysz się podstaw na żywym organizmie, tylko wnosisz już gotowy zestaw odruchów i nawyków.
Co to znaczy „umieć chmurę” na poziomie juniora
„Umieć chmurę” nie oznacza znać wszystkie usługi AWS/Azure/GCP na pamięć. Na poziomie juniora liczy się inny zestaw kompetencji: podstawowe klocki, umiejętność łączenia ich w sensowną całość i nawyk automatyzacji.
relacyjna baza zarządzana (RDS, Azure SQL, Cloud SQL),
podstawy backupu i retention.
IAM / tożsamość i uprawnienia:
użytkownicy, role, polityki,
różnice między uprawnieniami dla ludzi a dla serwisów (service principals, role, service accounts).
Podstawy automatyzacji:
Infrastructure as Code (Terraform/Bicep/CloudFormation),
prosty pipeline CI/CD do wdrażania kodu i infrastruktury.
Jeśli jesteś w stanie zbudować mały system obejmujący wszystkie te klocki, to na poziomie juniora jesteś w innym miejscu niż większość osób, które „poklikały kurs” i zatrzymały się na tworzeniu pojedynczej VM-ki w konsoli.
„Klikacz w konsoli” kontra junior, który rozumie architekturę
Najbardziej niszowa rola w chmurze to „klikacz w konsoli” – ktoś, kto potrafi na pamięć znaleźć ścieżkę do danego ustawienia w portalu AWS/Azure/GCP, ale nie rozumie, po co w ogóle to ustawienie istnieje. Firmy nie szukają ludzi do klikania. Szukają ludzi, którzy:
umieją odpowiedzieć na pytanie „dlaczego ta usługa jest tu potrzebna?”,
potrafią narysować prosty diagram systemu, nad którym pracują,
zastanawiają się nad konsekwencjami zmian (bezpieczeństwo, koszty, dostępność).
Na poziomie juniora różnica polega na tym, że nie tylko wykonujesz tutorial, ale też go modyfikujesz pod własne założenia. Zamiast klonować kurs, wprowadzasz własne decyzje: inny typ bazy, dodatkowy bucket, drugi region, logger, mechanizm backupu. Od tego zaczyna się myślenie architektoniczne.
Gdzie kończy się tutorial, a zaczyna samodzielny projekt
Tutorial jest przydatny jako start, ale niczego nie udowadnia na rozmowie technicznej, jeśli nie pójdziesz krok dalej. Granica jest prosta:
Tutorial: powtarzasz identyczne kroki, kopiujesz kod i screeny.
Projekt własny: zmieniasz wymagania, strukturę, dodajesz nowe komponenty, integrujesz kilka źródeł.
Dobrym sygnałem, że wyszedłeś poza tutorial, jest moment, gdy:
musisz doczytać dokumentację, bo twój wariant nie mieści się w kursie,
spędzasz czas w logach i na Stack Overflow, szukając przyczyny błędu,
zaczynasz świadomie projektować wersje środowisk (dev/test/prod) zamiast trzymać wszystko w jednej konfiguracji.
To właśnie to doświadczenie – walka z realnym problemem, a nie odtwarzanie nagrania – najlepiej przekłada się na rozmowę rekrutacyjną. Tech lead nie pyta: „ile kursów skończyłeś?”, tylko: „z jakim błędem w IAM męczyłeś się najdłużej i jak go znalazłeś?”.
Poziom głębokości: co ogarniać, a czego na razie nie ruszać
Przy samodzielnej nauce łatwo popaść w skrajności: albo uczysz się tylko „po powierzchni”, albo toniesz w szczegółach i normach, które w ogóle nie są potrzebne juniorowi. Rozsądny balans:
minimum jedną technologię compute (VM, kontener lub serverless),
usługę bazy danych + backup,
service do logowania i metryk,
IaC i proste CI/CD.
Można na razie odpuścić:
niuanse compliance (PCI-DSS, HIPAA) – wystarczy świadomość, że takie rzeczy istnieją,
zaawansowane usługi ML / Big Data, jeśli nie celujesz w data engineering,
szczegółowe parametry każdego typu instancji – ważniejsze jest zrozumienie kategorii (general purpose vs compute optimized).
Dla juniora lepiej mieć spójny zestaw kompetencji end-to-end na małym projekcie niż encyklopedyczną wiedzę o jednej niszowej usłudze.
Źródło: Pexels | Autor: MART PRODUCTION
Wybór platformy i kierunku: AWS, Azure, GCP czy miks
Większość początkujących w chmurze zadaje sobie to samo pytanie: którą platformę wybrać na start? Popularne rady są skrajne: „tylko AWS, bo największy rynek” albo „tylko Azure, bo firmy korpo mają Microsoft”. Prawda jest bardziej pragmatyczna.
Kiedy skupić się na jednej chmurze, a kiedy mieszać technologie
Na początku warto wybrać jedną chmurę jako główną. Powody są proste:
nazwy usług, modele uprawnień, sposób budowania sieci – wszystko ma swoją specyfikę,
na poziomie juniora liczy się głębokość w jednym ekosystemie bardziej niż powierzchowna znajomość trzech,
łatwiej zbudować spójny projekt end-to-end na jednej platformie.
Mieszanie technologii ma sens dopiero gdy:
masz już solidne podstawy w jednej chmurze,
celujesz w role typu multi-cloud (konsulting, większe software house’y),
chcesz znać odpowiedniki usług (np. S3 vs Blob Storage vs GCS) i różnice na wysokim poziomie.
Dobry kompromis dla juniora: jedna chmura na serio, reszta „świadomościowo”. To znaczy, że potrafisz wymienić główne usługi konkurencyjnych platform, ale nie próbujesz od razu robić w nich złożonych projektów.
Powiązanie wyboru platformy z rynkiem pracy i typem roli
Nie każda chmura ma taki sam udział w każdym kraju czy mieście. Zanim zaczniesz budować duże projekty, warto spojrzeć, czego faktycznie szukają pracodawcy w twoim regionie. Dobrze działa prosta analiza ogłoszeń na portalach z pracą.
Jak czytać ogłoszenia o pracę pod kątem wyboru chmury
Większość porad typu „wejdź w AWS, bo jest największy” ma jeden problem: ignorują lokalny rynek. Dwie godziny spędzone na analizie ofert potrafią lepiej ukierunkować naukę niż tygodnie kursów „w ciemno”. Sensowny sposób działania:
Wybierz 30–50 ogłoszeń na role: Cloud Engineer, DevOps, Site Reliability Engineer, Junior Cloud.
Zrób sobie krótką tabelkę: kolumny „AWS”, „Azure”, „GCP”, „inna chmura / prywatna”, plus narzędzia typu „Terraform”, „Docker”, „Kubernetes”, „CI/CD”.
Przejdź po ogłoszeniach i odhaczaj wystąpienia – nie analizuj głęboko, tylko policz, co dominuje.
Po kilkudziesięciu ogłoszeniach zaczną się rysować trendy:
jeśli w twoim mieście 70% ról cloudowych to Azure + .NET, uczenie się GCP „bo fajniejszy” jest ruchem hobbystycznym, nie zawodowym,
jeśli rynek jest mocno rozproszony (AWS/Azure/GCP po trochu), przewagę da Ci porządne ogarnięcie nawyków przenoszalnych (IaC, CI/CD, kontenery), zamiast fiksowania się na „jedynym słusznym” providerze.
Jest jedna pułapka: ogłoszenia często są pisane z myślą o idealnym kandydacie. Jeśli w każdym opisie jest „AWS/Azure/GCP”, jeszcze nie znaczy, że musisz znać wszystkie trzy. Często wystarczy solidna znajomość jednego plus świadomość różnic w pozostałych.
Jak dobrać chmurę do swojego profilu: dev, ops, data
Wybór platformy dobrze skorelować z tym, jaką rolę widzisz u siebie za 2–3 lata:
Bliżej Ci do developera (piszesz backend, lubisz kod):
silny ekosystem .NET / C# w regionie → Azure jako naturalny wybór,
dużo Node/Java/Python → AWS lub GCP, w zależności od lokalnego rynku.
Bliżej Ci do ops / infrastruktury:
AWS i Azure oferują większą liczbę ról stricte infrastrukturalnych,
GCP częściej pojawia się przy firmach produktowych i startupach.
Interesuje Cię data / analityka:
AWS i GCP mają bardzo mocne portfolio usług data/ML,
Azure z kolei naturalnie łączy się ze światem Power BI / SQL Server.
Popularna rada „ucz się tej chmury, którą masz w obecnej firmie” ma sens tylko wtedy, gdy:
rzeczywiście będziesz mieć choć pośredni dostęp do środowisk,
firma inwestuje w rozwój (mentoring, laby, czas na naukę),
to jest ta sama chmura, której potem oczekuje rynek rekrutacyjny w Twoim regionie.
Jeśli pracujesz w niszowej technologii, której prawie nie ma w ogłoszeniach, lepiej traktować ją jako bonus i równolegle inwestować w platformę dominującą na rynku.
Jak zorganizować swoje „środowisko produkcyjne na niby”
Zamiast marzyć o dostępie do firmowej produkcji, szybciej dojdziesz do celu, budując własne pseudo-środowisko. Chodzi o to, żeby zasymulować realne ograniczenia: koszty, uprawnienia, procesy, a nie tylko „mieć konto trial i klikać”.
Architektura kont i subskrypcji dla jednej osoby
Popularne podejście to jedno konto w chmurze i wszystko wrzucone do jednego projektu. Efekt: bałagan, brak rozdzielenia środowisk, trudniej potem pokazać dojrzałość na rozmowie. Dużo lepszy wariant: struktura zbliżona do firmowej, nawet jeśli jesteś jedyną osobą w projekcie.
Przykładowy model (AWS, ale w Azure/GCP robisz odpowiedniki):
konto „dev” – środowisko deweloperskie, gdzie możesz szaleć,
konto „prod” – środowisko „jak produkcja”, z ostrzejszymi zasadami.
Oddzielne role IAM:
„admin-dev” – pełne prawa w dev,
„read-only-prod” – tylko podgląd w prod,
„deployer-prod” – uprawnienia do wdrożeń z CI/CD, ale bez możliwości ręcznego grzebania w konsoli.
Na poziomie hobby to może wyglądać przesadnie, ale na rozmowie możesz pokazać, że rozumiesz segregację obowiązków, rozdzielanie środowisk i minimalne uprawnienia – czyli to, czym żyje każdy zespół chmurowy.
Budżet, limity i „polityka kosztowa” dla samego siebie
Brak budżetu jest częstą wymówką: „nie stać mnie na naukę w chmurze”. Tymczasem większość problemów z rachunkami to nie wysokość budżetu, tylko brak kontroli. Zamiast bać się kosztów, lepiej nauczyć się nimi zarządzać tak, jak robią to firmy.
Praktyczne elementy, które da się ustawić w jeden wieczór:
Budżet i alerty – włącz budżet miesięczny (np. 10–20 USD) i ustaw alerty mailowe / SMS na 50%, 80%, 100%. To wymusza reagowanie zanim pojawi się przykra niespodzianka.
Firmy bardzo cenią kogoś, kto od początku ma nawyk kontroli kosztów. Jeśli na rozmowie mówisz o tym, jak ubiłeś nieużywany load balancer albo wdrożyłeś automatyczne wyłączanie instancji, wyróżniasz się na tle kandydatów, którzy „nigdy o tym nie myśleli”.
Procesy jak w firmie: ticket, review, deployment
Praca w chmurze to nie tylko kliknięcie „Create”. W realnych zespołach każda zmiana ma jakiś proces. Da się to zasymulować solo, nawet jeśli brzmi to dziwnie („robić code review samemu ze sobą”). Przykładowy prosty workflow:
Tworzysz ticket w swoim narzędziu (Jira, GitHub Issues, Trello) – np. „dodać nowy endpoint API i wystawić go przez load balancer”.
Pracujesz zawsze w oddzielnym branchu git – dotyczy to zarówno aplikacji, jak i IaC.
Robisz pull request i świadomie go przeglądasz:
czy IaC jest idempotentne,
czy nie łamiesz własnych reguł bezpieczeństwa,
czy zmiana jest minimalna („small batch”), a nie refactoring całego świata.
Merge do main wyzwala pipeline CI/CD, który:
buduje artefakty,
wdraża na dev, odpala testy dymne,
po ręcznym „approve” wypycha zmiany na pseudo-prod.
Na papierze wygląda to jak zabawa w firmę. W praktyce wyrabia mięśnie, które potem wykorzystasz natychmiast po wejściu do zespołu: pisanie ticketów, podział pracy na małe zadania, pilnowanie jakości w PR-ach.
Źródło: Pexels | Autor: MART PRODUCTION
Typy projektów chmurowych, które imitują doświadczenie produkcyjne
„Zrób projekt w chmurze” brzmi dobrze, ale jest zbyt ogólne. Dużo bardziej użyteczne jest myślenie kategoriami: jaki rodzaj problemu biznesowego chcę rozwiązać, jakie aspekty pracy cloudowca chcę przećwiczyć. Nie każdy projekt ćwiczy to samo.
Mała aplikacja webowa z trzema środowiskami
To klasyka, ale nadal zbyt rzadko robiona porządnie. Cel: mieć prostą aplikację (np. TODO, blog, mini-API), ale zorganizowaną tak, jakby korzystały z niej tysiące użytkowników, nawet jeśli realnie nikt poza Tobą tam nie zagląda.
Elementy, które zmieniają prostą aplikację w mini-produkcję:
Trzy środowiska: dev, test, prod – każde jako osobny zestaw zasobów w chmurze.
Oddzielne bazy danych – brak wspólnej bazy „na wszystko”.
Wersjonowane deploymenty – release’y oznaczone tagami git w historii.
Monitoring – podstawowe metryki (CPU, RAM, latency) i logi aplikacji widoczne w jednym miejscu.
Proste SLA – nawet jeśli wymyślone: np. „aplikacja dostępna 99% czasu w miesiącu”, a Ty pilnujesz, czy to realne.
Na rozmowie technicznej łatwiej opowiedzieć o projekcie, gdy możesz powiedzieć: „miałem trzy środowiska, wprowadziłem flagi feature’ów, zrobiłem migracje bazy wersjonowane w CI/CD”. To brzmi jak praca w realnym zespole, nie jak ukończony tutorial.
Projekt „data pipeline” – od źródła do dashboardu
Drugi typ projektu, który mocno punktuje, to prosty pipeline danych. Nie trzeba być data engineerem, żeby zbudować sensowną ścieżkę: pobieranie danych → przetwarzanie → składowanie → wizualizacja.
Minimalny scenariusz:
Źródło danych: publiczne API (np. prognoza pogody, kursy walut) lub CSV wrzucany codziennie do bucketu.
albo prosty job kontenerowy uruchamiany cyklicznie.
Składowanie: relacyjna baza zarządzana lub data warehouse w wersji „lite”.
Wyjście: prosty dashboard (np. Grafana, Metabase) albo raport generowany codziennie i wrzucany do S3/Blob/GCS.
Taki projekt uczy nie tylko usług chmurowych, ale też planowania przepływu danych, harmonogramu jobów, idempotentności (job może się uruchomić dwa razy i nic nie popsuje). To są realne problemy produkcyjne, które często wychodzą dopiero „w boju”.
„Platforma dla developerów” – mini internal PaaS
Mniej oczywista, ale bardzo cenna ścieżka: zbudować coś, co udaje platformę wewnętrzną dla innych devów. Nawet jeśli jesteś jedynym użytkownikiem. Typowy scenariusz:
tworzą standardowe środowisko pod mikroserwis (VPC, subnety, baza, logowanie, bucket na pliki),
mają parametry: nazwa serwisu, rozmiar instancji, rodzaj bazy.
Dodajesz szablony pipeline’ów CI/CD:
standard build, test, deploy dla aplikacji w kontenerze lub serverless,
gotowe kroki do deploymentu infrastruktury.
Opisujesz to w README tak, jakby ktoś inny miał z tego korzystać.
Na rozmowie możesz wtedy opowiadać nie tylko o „apce X”, ale o tym, że standaryzowałeś sposób budowy środowisk. To jest dokładnie to, czym żyją zespoły platformowe i DevOps w większych organizacjach.
Projekt nastawiony na bezpieczeństwo („secure-by-default”)
Większość projektów juniorów pomija bezpieczeństwo. W efekcie powstają publiczne S3, bazy dostępne z internetu i hasła w plain text w repozytorium. Zrobienie bezpiecznego z domysłu projektu nawet o prostej funkcjonalności daje ogromną przewagę.
Konkrety, które można wdrożyć od razu:
Brak publicznych IP dla baz danych i serwisów backendowych – dostęp tylko z VPC lub przez bastion/VPN.
Wymuszone szyfrowanie:
kryptografia w spoczynku (encryption at rest) dla bucketów i baz,
HTTPS wszędzie, nawet w dev.
Secrets manager zamiast plików .env w repo.
Least privilege w IAM – role z minimalnym zakresem, zamiast „AdministratorAccess na wszystko”.
Projekt nastawiony na koszt i niezawodność („tanio, ale nie byle jak”)
Popularna rada brzmi: „włącz wszystko na najwyższych parametrach, żeby było jak w prawdziwej produkcji”. Tyle że w realnym świecie mało który zespół może sobie pozwolić na bezrefleksyjne „najwyższe tier’y”. Bardziej przypomina to ciągłą walkę o balans: jak nie przepalać budżetu, a jednocześnie nie zabijać SLA.
Da się to zasymulować nawet przy bardzo małych pieniądzach, jeśli założysz sobie sztuczne ograniczenia:
Twardy limit miesięczny – np. 15 USD jako „budżet klienta” na cały system.
„SLA” z karą – jeśli Twoja apka nie działa przez X minut dziennie (liczone przez prosty healthcheck z zewnątrz), „płacisz karę” – np. musisz poświęcić dodatkowy wieczór na analizę przyczyn i poprawki.
Zasada: najpierw taniej, potem szybciej – dopóki nie udowodnisz, że potrzebujesz droższej usługi, szukasz tańszego wariantu (np. serverless zamiast stałych VM-ek).
Co można z tego wyciągnąć praktycznie:
Porównaj dwie architektury dla tej samej aplikacji:
wersję „ciężką”: VM-ki, stałe load balancery, zarządzana baza w wyższym tierze,
wersję „lekką”: funkcje serverless, API Gateway, tańsza baza/serverless DB lub nawet rozsądnie użyty storage obiektowy.
Zmierz koszty i prostotę utrzymania po tygodniu lub dwóch.
Dodaj mechanizmy degradacji: jeśli baza nie wyrabia, aplikacja przechodzi w tryb „read-only” zamiast się wywalać. To można zasymulować choćby flagą konfiguracyjną wymuszaną w pipeline.
Eksperymentuj z autoscalingiem na ograniczonych zasobach – ustaw minimalną i maksymalną liczbę instancji, monitoruj, czy w godzinach „szczytu” (np. gdy sam generujesz ruch) aplikacja nadal reaguje sensownie.
Taki projekt pokazuje, że nie myślisz tylko nazwami usług, ale widzisz związek między techniką, rachunkiem i niezawodnością. Dla rekrutera to sygnał, że nie będziesz pierwszą osobą, która włączy najdroższy tier, bo „ktoś w internecie tak doradził”.
Projekt „od zera do działającej chmury”: przykładowy scenariusz krok po kroku
Same pojedyncze projekty są dobre na start, ale w pewnym momencie trzeba spróbować czegoś bardziej całościowego: od założenia konta po działającą aplikację z monitoringiem i deploymentem. To jeszcze nie jest produkcja, ale zaczyna ją przypominać pod względem liczby ruchomych elementów.
Krok 1: Założenie konta i podstawowa „gwardia przybramna”
Zanim powstanie jakikolwiek serwer, ustaw kilka rzeczy, które w firmach robi się na początku – i które często są lekceważone przez osoby uczące się na własną rękę.
Uwierzytelnianie wieloskładnikowe (MFA) na głównym koncie i na pierwszych użytkownikach IAM / AAD.
Osobne konto / subscription na zabawki – nawet jeśli to tylko „dev”, trzymaj się zasady: niczego krytycznego tam nie będzie, wszystko można skasować bez bólu.
Organizacja użytkowników i ról:
konto „root” tylko do operacji administracyjnych,
osobny użytkownik do codziennej pracy, z rolą ograniczoną do tego, co ćwiczysz.
Ten etap wydaje się nudny, ale to on odróżnia „przeklikałem tutorial” od „znam podstawy higieny chmurowej”.
Krok 2: Fundament sieciowy i zasady bezpieczeństwa
Zamiast zaczynać od „postawmy serwer i zobaczmy, czy działa”, zacznij od czegoś, co większość zespołów musi ogarnąć bardzo wcześnie – sieć.
Stwórz jedno VPC / Virtual Network z:
publiczną podsiecią pod load balancery / bramki,
prywatną podsiecią pod bazy danych i backend.
Zdefiniuj Security Group / NSG, które:
pozwalają na ruch HTTP/HTTPS tylko do warstwy frontend / API z internetu,
ograniczają dostęp do bazy wyłącznie z backendu.
Dodaj logowanie ruchu sieciowego na minimum: flow logi do bucketu i prostą analizę (np. kwerenda w narzędziu typu CloudWatch Logs, Log Analytics).
Po tym kroku masz z grubsza to, czym żyje wiele zespołów: prywatną przestrzeń sieciową i podstawowy „mur” między internetem a backendem.
Krok 3: Wybór modelu compute i postawienie pierwszej aplikacji
Klasyczna rada: „postaw VM-kę, wrzuć tam aplikację, potem kiedyś się pomyśli o kontenerach”. To ma sens edukacyjny, ale szybko kończy się powtarzaniem tych samych kroków. Alternatywą jest podejście: postaraj się od razu przećwiczyć dwa modele.
Przykład:
Prosty backend REST napisany w dowolnym języku:
wersja 1 – jako aplikacja na VM / App Service / Compute Engine,
wersja 2 – jako kontener na managed Kubernetes / ECS / Cloud Run lub funkcje serverless.
Dla obu wersji:
wystaw API za load balancerem / API Gateway,
zadbaj o certyfikaty TLS (np. z wbudowanego managera certyfikatów).
Porównując obie ścieżki, zaczynasz rozumieć, w jakich scenariuszach prosta VM-ka jest OK, a kiedy warto od razu myśleć o kontenerach albo funkcjach.
Krok 4: Trwałe dane i migracje
Bez bazy danych trudno mówić o jakiejkolwiek produkcji. Zamiast po prostu „kliknąć bazę”, zrób to tak, jak robią to zespoły.
Zainstaluj prosty system migracji schematu (Flyway, Liquibase, narzędzie wbudowane w framework) i:
dodawaj zmiany schematu zawsze przez migracje,
odpalaj migracje z pipeline’u CI/CD przy każdym wdrożeniu.
Skonfiguruj backup bazy:
automatyczne snapshoty,
test przywrócenia na osobnej instancji raz na jakiś czas.
Symulacja awarii bazy (np. skasowanie danych na dev i przywrócenie ze snapshotu) to lepsza nauka niż dziesięć artykułów o „strategiach backupu”.
Krok 5: Monitoring, logi i proste alerty
System, którego nikt nie widzi, „działa” tylko do pierwszego problemu. To moment, w którym aplikacja staje się bardziej „produkcyjna”: ktoś musi wiedzieć, że jest źle, zanim zaczną dzwonić użytkownicy – w Twoim przypadku zanim sam się na to natkniesz przypadkiem.
Skieruj wspólne logi do jednego miejsca (CloudWatch/Log Analytics/Stackdriver), zamiast zostawiać je rozproszone po VM-kach.
Skonfiguruj co najmniej 2–3 alerty:
niedostępność endpointu healthcheck,
wysokie opóźnienia odpowiedzi,
gwałtowny wzrost błędów 5xx.
Alerty ustaw początkowo do siebie (mail, Slack, cokolwiek), ale traktuj je jak „pager duty”: jeśli przychodzą w nocy, zastanów się, jak zmienić progi lub architekturę, żeby nie budziły Cię z błahych powodów. To świetne ćwiczenie na balans między wrażliwością a hałasem.
Krok 6: CI/CD od commit’a do pseudo-produkcji
Masz już infrastrukturę, aplikację i monitoring. Kolejny etap to poskładanie tego w całość tak, żeby każda zmiana kodu przechodziła przez ten sam, powtarzalny proces.
Wybierz jedno narzędzie CI/CD (GitHub Actions, GitLab CI, Azure DevOps, cokolwiek) i zrób:
pipeline dla aplikacji (build, test, deploy),
pipeline dla infrastruktury (walidacja, plan, apply z approvalem).
Zadbaj o artefakty:
obrazy kontenerów w prywatnym rejestrze,
paczki aplikacyjne podpisane tagiem git.
Oddziel deployment na dev i pseudo-prod:
dev – automatycznie po merge’u do main,
pseudo-prod – po ręcznym zatwierdzeniu, z odnotowaniem wersji i linkiem do ticketu.
To moment, w którym Twoje „środowisko na niby” zaczyna wyglądać jak prawdziwy ekosystem: kod, infrastruktura i procesy grają razem, a nie są przypadkowymi kliknięciami w konsoli.
Jak ćwiczyć operacje i utrzymanie bez prawdziwych awarii
Największa iluzja juniorów: „jak będę dobrze projektować, to nie będzie awarii”. W produkcji zawsze coś się psuje – od błędu w kodzie, przez limit połączeń, po rachunek nieopłacony na czas. Zamiast czekać, aż prawdziwa awaria Cię zaskoczy, można ją zaplanować i przećwiczyć w bezpiecznym sandboxie.
Kontrolowane „psucie” środowiska
Popularna rada to „włącz chaos engineering, zainstaluj narzędzie X”. Dla juniora kończy się to często losowym zabijaniem instancji bez zrozumienia, o co chodzi. Dużo skuteczniejsze na początek jest ręczne, świadome psucie pojedynczych elementów i obserwacja skutków.
Kilka scenariuszy, które można przeprowadzić samodzielnie:
Zabicie instancji aplikacji:
wyłącz jedną z replik w autoscalingu albo ręcznie skasuj instancję,
obserwuj, jak reaguje load balancer i czy autoscaling faktycznie odtwarza instancję.
Symulacja awarii bazy:
na dev wyłącz instancję bazy lub zablokuj port,
zobacz, jak zachowuje się aplikacja – czy loguje sensowny błąd, czy rzuca stacktrace do użytkownika.
Przekroczenie limitów zasobów:
zmniejsz rozmiar instancji lub przydziały CPU/RAM dla kontenera,
uruchom test obciążeniowy i sprawdź, czy aplikacja degraduje się „ładnie” (np. timeouty, komunikaty o przeciążeniu) czy po prostu pada.
Po każdym takim eksperymencie dopisz krótką notatkę: „co się stało, jak użytkownik to widział, jak mogę to poprawić następnym razem”. To mini postmortem – na rozmowie rekrutacyjnej możesz pokazać, że nie tylko coś zbudowałeś, ale też świadomie je „rozbijałeś o skały”.
Runbooki i procedury na „3 w nocy”
W wielu firmach ktoś na dyżurze ma do dyspozycji runbook – prosty dokument: „jeśli alert X, to sprawdź A/B/C, potem zrób D”. Juniorzy rzadko kiedy widzieli taki dokument od środka; można to zmienić, tworząc swoje wersje, nawet jeśli jedyną osobą „na dyżurze” jesteś Ty.
Proste ćwiczenie:
Wybierz 3–4 typowe problemy, np.:
aplikacja przestała odpowiadać,
baza odrzuca połączenia,
nagły skok błędów 5xx,
rachunek zbliża się do limitu budżetu.
Dla każdego napisz runbook:
jakie dashboardy i logi sprawdzasz po kolei,
jakie komendy / zapytania uruchamiasz (np. kwerendy w logach),
jakie masz możliwe akcje naprawcze (restart, skalowanie, rollback, wyłączenie niekrytycznego modułu).
Potem zasymuluj alert (np. ręcznie wywołaj go, psując coś w kontrolowany sposób) i odpal runbook krok po kroku. Bardzo szybko wyjdzie, że brakuje Ci jakiejś metryki albo logu – to naturalny mechanizm ulepszania systemu.
Ćwiczenie rollbacków i „wydawania hotfixów”
Świat idealny: każdy deployment jest bezbłędny. Świat realny: prędzej czy później trzeba się wycofać lub wypchnąć szybki hotfix. Lepsze, żeby pierwszy raz stało się to na Twoim koncie testowym, niż na środowisku klienta.
