Pytania rekrutacyjne dla inżyniera niezawodności systemów (SRE) — ponad 30 pytań i eksperckie odpowiedzi

Glassdoor podaje średnie wynagrodzenie SRE na poziomie 169 680 USD, przy czym 75. percentyl przekracza 213 000 USD rocznie [1]. Ta rola — zrodzona w Google w 2003 roku i obecnie stosowana we wszystkich głównych firmach technologicznych — znajduje się na styku inżynierii oprogramowania i operacji systemowych, a proces rekrutacyjny odzwierciedla tę dwoistość [2]. Rozmowy kwalifikacyjne SRE sprawdzają projektowanie systemów z uwzględnieniem ograniczeń niezawodności, kodowanie na potrzeby automatyzacji, zarządzanie incydentami pod presją oraz specyficzny sposób myślenia polegający na kwantyfikacji niezawodności poprzez SLO i budżety błędów. Ten przewodnik obejmuje pytania behawioralne, techniczne i sytuacyjne, z odpowiedziami skalibrowanymi do poziomu oczekiwanego przez czołowe firmy.

Kluczowe wnioski

• Rozmowy SRE obejmują zazwyczaj cztery do sześciu rund: kodowanie, projektowanie systemów, rozwiązywanie problemów, zarządzanie incydentami i pytania behawioralne — rozłożone na cały dzień lub kilka sesji [3].
• Kluczowym wyróżnikiem rozmów SRE jest projektowanie systemów zorientowane na niezawodność — musisz projektować systemy, które degradują się łagodnie, a nie tylko systemy, które się skalują [2].
• SLO, SLI, budżety błędów i redukcja pracy powtarzalnej (toil) to specyficzny słownik SRE, którego biegłego używania oczekują rekruterzy.
• Pytania programistyczne dla ról SRE kładą nacisk na automatyzację, narzędzia infrastrukturalne i skrypty operacyjne, a nie czysto algorytmiczne zagadki [3].

Pytania behawioralne

1. Opowiedz o najważniejszym incydencie, którym zarządzałeś. Jaka była twoja rola i co ujawniła analiza post-mortem?

Odpowiedź eksperta: „Byłem dowódcą incydentu podczas kaskadowej awarii, która wyłączyła nasz główny serwis uwierzytelniania, dotykając 2,3 miliona aktywnych użytkowników na 47 minut. Rutynowa zmiana konfiguracji naszego limitera szybkości przypadkowo ustawiła próg na 10 żądań na sekundę zamiast 10 000. Serwis auth osiągnął limit, zwracał kody 429, a burza ponownych prób od klientów wzmocniła obciążenie 50-krotnie. Ogłosiłem P1, ustanowiłem kanał incydentu, przydzieliłem role i skoordynowałem odpowiedź. Naprawa polegała na wycofaniu zmiany konfiguracji, ale musieliśmy też opróżnić kolejkę ponownych prób, tymczasowo zwiększając pojemność. Analiza post-mortem zidentyfikowała trzy przyczyny źródłowe: brak walidacji wartości konfiguracji limitera, brak wdrożenia kanarkowego dla zmian konfiguracji i brak wyłącznika obwodowego dla ponownych prób klienta. Wdrożyliśmy wszystkie trzy poprawki i dodaliśmy syntetycznego kanarka testującego przepływ auth co 30 sekund. Incydent zużył 40% naszego kwartalnego budżetu błędów, co uruchomiło zamrożenie rozwoju nowych funkcji do czasu wdrożenia ulepszeń niezawodności."

2. Opisz sytuację, w której wyeliminowałeś znaczące źródło pracy powtarzalnej (toil).

Odpowiedź eksperta: „Nasi inżynierowie dyżurni spędzali średnio 6 godzin tygodniowo na ręcznym skalowaniu replik odczytu bazy danych podczas skoków ruchu. Zbudowałem kontroler auto-skalowania za pomocą niestandardowego operatora Kubernetes, który monitorował metryki CPU i opóźnień zapytań, obliczał wymaganą liczbę replik na podstawie modelu predykcyjnego i skalował repliki automatycznie. Dodałem zabezpieczenia: minimalne i maksymalne liczby replik, okresy schładzania i alerty PagerDuty. Interwencje ręcznego skalowania spadły z 6 godzin/tydzień do 0, a obciążenie dyżurne zmniejszyło się o 30%."

3. Podaj przykład, jak sprzeciwiłeś się wymaganiu niezawodności, które uważałeś za zbyt agresywne.

Odpowiedź eksperta: „Zespół produktowy zażądał 99,999% dostępności dla nowego serwisu powiadomień. Obliczyłem, co pięć dziewiątek rzeczywiście oznacza: 5,26 minuty przestoju rocznie. Koszt inżynieryjny oszacowano na 6 miesięcy i 400 000 USD dodatkowej infrastruktury. Zaproponowałem 99,9% dostępności, które nasza istniejąca infrastruktura mogła osiągnąć przy niewielkich ulepszeniach. Zespół produktowy zgodził się po zobaczeniu krzywej kompromisu koszt-niezawodność. To jest dyscyplina SRE: niezawodność to funkcja, a jak każda funkcja, ma koszt, który musi być uzasadniony wpływem na użytkownika [2]."

4. Opowiedz o sytuacji, gdy poprawiłeś monitoring lub obserwowalność krytycznego serwisu.

Odpowiedź eksperta: „Nasz serwis płatności miał monitoring śledzący tylko podstawowe sprawdzenia kondycji. Po cichej awarii, gdy serwis zwracał 200, ale ze stałymi danymi z cache przez 3 godziny, przeprojektowałem nasz stos obserwowalności. Zdefiniowałem SLI powiązane z doświadczeniem użytkownika, wdrożyłem metryki Prometheus, utworzyłem dashboardy Grafana z alertami szybkości spalania SLO i dodałem rozproszone śledzenie z Jaeger. Alertowanie wielookienkowe zmniejszyło fałszywe alarmy o 60%."

5. Opisz, jak równoważyłeś tempo rozwoju funkcji z pracami nad niezawodnością.

Odpowiedź eksperta: „Wdrożyłem politykę budżetu błędów, w której prace nad niezawodnością i rozwój funkcji były zarządzane tą samą metryką. Gdy budżet był powyżej 50%, zespół deweloperski miał pełną prędkość na funkcje. Poniżej 50% dzieliliśmy 50/50. Poniżej 25% cała praca inżynieryjna przechodziła na niezawodność. W ciągu roku wskaźnik incydentów P1 spadł o 45%, a zespół produktowy wydał 12% więcej funkcji niż w poprzednim roku."

6. Jak podchodzisz do rotacji dyżurnych i jak poprawiłeś doświadczenie dyżurowe swojego zespołu?

Odpowiedź eksperta: „Traktuję dyżur jako problem inżynieryjny. Gdy dołączyłem, dyżurni otrzymywali średnio 14 powiadomień tygodniowo, z 40% nieakcjowalnych. Wdrożyłem strojenie alertów, automatyzację runbooków i ustrukturyzowane przekazanie dyżuru. Powiadomienia spadły z 14/tydzień do 4/tydzień, a wynik satysfakcji z dyżuru wzrósł z 2,1/5 do 4,3/5."

Pytania techniczne

1. Wyjaśnij SLO, SLI i budżety błędów. Jak się ze sobą łączą?

Odpowiedź eksperta: „SLI to ilościowa metryka mierząca konkretny aspekt jakości usługi. SLO to docelowa wartość dla SLI. Budżet błędów to odwrotność SLO: jeśli twoje SLO wynosi 99,9%, budżet błędów to 0,1%. Budżet błędów tworzy wspólny język między SRE a zespołami produktowymi: dopóki mieścisz się w budżecie, agresywnie wydawaj funkcje. Gdy budżet jest zużyty, inwestuj w niezawodność [2]."

2. Zaprojektuj system monitoringu i alertowania dla architektury mikroserwisowej z 50 serwisami.

Odpowiedź eksperta: „Zbudowałbym system w trzech warstwach. Zbieranie danych: instrumentacja każdego serwisu bibliotekami klienta Prometheus eksportującymi metryki RED. Agregacja logów przez Loki lub Elasticsearch. Rozproszone śledzenie przez Jaeger lub Tempo. Alertowanie: SLO dla krytycznych ścieżek użytkownika z alertowaniem wielookienkowym szybkości spalania. Dashboardy: złote sygnały per serwis, dashboard SLO najwyższego poziomu i mapy zależności serwisów. Kluczowa zasada: alerty na symptomy (wpływ na użytkownika), nie przyczyny (wysokie CPU)."

3. Serwis odpowiada wolno. Przeprowadź mnie przez swoje podejście do diagnozowania.

Odpowiedź eksperta: „Zaczynam od wpływu na użytkownika: jakie jest opóźnienie P50/P99 w porównaniu z normą? Następnie stosuję metody USE i RED systematycznie. Sprawdzam sam serwis, zależności downstream, sieć. Używam rozproszonego śledzenia do identyfikacji, który span przyczynia się do największego opóźnienia."

4. Jak zaprojektowałbyś system osiągający 99,99% dostępności w wielu regionach?

Odpowiedź eksperta: „99,99% dopuszcza 52,6 minuty przestoju rocznie. Architektura: aktywne-aktywne wdrożenie w co najmniej 3 regionach. Globalne równoważenie obciążenia z przełączaniem ruchu opartym na sprawdzeniach kondycji. Warstwa danych: replikacja synchroniczna w regionach, asynchroniczna między regionami. Wdrożenia kanarkowe per region. Regularna inżynieria chaosu do weryfikacji przełączania awaryjnego."

5. Jaka jest różnica między skalowaniem horyzontalnym a wertykalnym i kiedy preferujesz każde z nich?

Odpowiedź eksperta: „Skalowanie wertykalne zwiększa zasoby jednej instancji. Skalowanie horyzontalne dodaje więcej instancji za load balancerem. Preferuję skalowanie horyzontalne dla serwisów bezstanowych, a wertykalne dla komponentów stanowych, gdzie skalowanie horyzontalne wprowadza złożoność."

6. Wyjaśnij infrastrukturę jako kod (IaC) i jak użyłeś jej do poprawy niezawodności.

Odpowiedź eksperta: „IaC traktuje konfigurację infrastruktury jak oprogramowanie: wersjonowana, przeglądana, testowana i reprodukowalna. Używam Terraform do provisioningu zasobów chmurowych i Ansible do zarządzania konfiguracją. Korzyści: reprodukowalność, audytowalność i testowalność."

7. Jak podchodzisz do planowania pojemności dla szybko rosnącego serwisu?

Odpowiedź eksperta: „Stosuję czteroetapowy framework: ustalenie modelu obciążenia, modelowanie wzrostu, identyfikacja zasobu wąskiego gardła i automatyzacja odpowiedzi. Przeglądam plany pojemności co miesiąc, porównując prognozy z rzeczywistością."

Pytania sytuacyjne

1. Budżet błędów twojego serwisu jest wyczerpany na dwa tygodnie przed końcem kwartału. Zespół produktowy chce wydać ważną funkcję. Co robisz?

Odpowiedź eksperta: „Zgodnie z polityką budżetu błędów, wyczerpanie budżetu uruchamia zamrożenie niezawodności. Przedstawiłbym dane zespołowi produktowemu i zaproponował alternatywy: wdrożenie za flagą funkcji z stopniowym rollout'em lub priorytetyzacja konkretnego ulepszenia niezawodności. Polityka budżetu błędów istnieje właśnie na takie sytuacje [2]."

2. Zmiana młodszego inżyniera spowodowała awarię produkcyjną. Jak prowadzisz post-mortem?

Odpowiedź eksperta: „Fundamentalną zasadą jest bezobwinianie — post-mortem bada co się stało i dlaczego system na to pozwolił, nigdy kto jest winny [2]. Działania naprawcze powinny poprawiać system, nie karać inżyniera."

3. Dziedziczysz system legacy bez monitoringu, dokumentacji i testów. Od czego zaczynasz?

Odpowiedź eksperta: „Priorytetyzuję według promienia rażenia. Tydzień 1: podstawowy monitoring. Tygodnie 2-4: dokumentacja architektury. Miesiąc 2: testy integracyjne dla krytycznej ścieżki. Miesiąc 3: CI/CD. Kluczowa zasada: nie przepisuj, stabilizuj."

4. Monitoring pokazuje powolny wyciek pamięci w produkcji. Serwis się zawiesza i restartuje co 72 godziny. Jak podchodzisz do tego?

Odpowiedź eksperta: „Najpierw kwantyfikuję wpływ. Dla dochodzenia: włączam profilowanie heap i porównuję migawki w regularnych odstępach. Krótkoterminowe: łagodny restart co 48 godzin. Długoterminowe: po zidentyfikowaniu wyciekającego typu obiektów naprawiam przyczynę źródłową i dodaję SLI użycia pamięci."

5. Kierownictwo prosi o obniżenie kosztów infrastruktury o 30% przy zachowaniu obecnego poziomu niezawodności. Jak podchodzisz?

Odpowiedź eksperta: „Identyfikuję możliwości w czterech kategoriach: right-sizing instancji, pojemność zarezerwowana, instancje spot/preemptible i optymalizacja architektury. Niezawodność nie podlega negocjacjom — redukcja kosztów pochodzi z efektywności, nie z usuwania redundancji."

Pytania do rekrutera

1. „Jakie są SLO dla serwisów, za które ten zespół odpowiada, i jak zarządzane są budżety błędów?"
2. „Jak wygląda rotacja dyżurna — ilu inżynierów, jaki wolumen alertów, jaka polityka eskalacji?"
3. „Jak zespół równoważy pracę projektową z pracą operacyjną?"
4. „Jak wygląda relacja zespołu z zespołami deweloperskimi — SRE osadzone czy scentralizowane?"
5. „Jakie jest podejście zespołu do post-mortemów — czy są bezobwiniające i jaki procent działań naprawczych jest realizowany?"
6. „Jaką infrastrukturę i narzędzia zespół zarządza?"
7. „Jakie są największe wyzwania niezawodności, z którymi zespół się obecnie mierzy?"

Format rozmowy i czego się spodziewać

Rozmowy SRE w głównych firmach technologicznych obejmują zazwyczaj 4-6 godzin [3]. Runda kodowania testuje Python/Go/Java z problemami skupionymi na automatyzacji. Runda projektowania systemów wymaga projektowania z jawnymi ograniczeniami niezawodności. Runda rozwiązywania problemów przedstawia scenariusz produkcyjny. Runda behawioralna ocenia doświadczenie dyżurne i zarządzanie incydentami. Cały proces trwa zazwyczaj 3-6 tygodni.

Jak się przygotować

• Przestudiuj książkę Google SRE. Rozdziały o SLO, budżetach błędów, toil i zarządzaniu incydentami są fundamentalne [2].
• Ćwicz projektowanie systemów z ograniczeniami niezawodności.
• Przygotuj historie incydentów. 3-5 szczegółowych narracji.
• Powtórz podstawy Linuxa. Zarządzanie procesami, operacje systemu plików, narzędzia sieciowe.
• Ćwicz kodowanie na potrzeby automatyzacji.
• Znaj swój stos obserwowalności.

Typowe błędy na rozmowach

1. Projektowanie na skalę bez projektowania na awarię [2].
2. Brak kwantyfikacji niezawodności.
3. Traktowanie incydentów jako czysto technicznych problemów.
4. Ignorowanie toil.
5. Nadmierne inżynierowanie rozwiązań [2].
6. Brak zrozumienia modelu budżetu błędów.
7. Brak wykazania umiejętności programistycznych [3].

Kluczowe wnioski

• Rozmowy SRE testują specyficzny sposób myślenia inżynieryjnego: kwantyfikację niezawodności, podejmowanie decyzji opartych na danych i traktowanie operacji jako problemów inżynierii oprogramowania.
• SLO, SLI, budżety błędów i toil to słownik SRE — używaj go biegle.
• Przygotuj szczegółowe historie incydentów.
• Odpowiedzi dotyczące projektowania systemów muszą zawierać jawne tryby awarii i strategie łagodnej degradacji.

Chcesz się upewnić, że twoje CV zaprowadzi cię na rozmowę? Wypróbuj darmowy sprawdzacz wyniku ATS od ResumeGeni, aby zoptymalizować swoje CV inżyniera niezawodności systemów.

FAQ

Jaka jest różnica między SRE a DevOps?

SRE to konkretna implementacja zasad DevOps z preskryptywnymi praktykami: SLO, budżety błędów, budżety toil i zdefiniowany model współpracy z zespołami deweloperskimi [2].

Jakie języki programowania powinienem znać na rozmowy SRE?

Python i Go są najczęściej używanymi językami w SRE [3].

Jakiego zakresu wynagrodzeń powinienem się spodziewać jako SRE?

Wynagrodzenia wahają się od 128 842 USD do 169 680 USD, z 75. percentylem na poziomie 213 272 USD [1].

Jak ważna jest książka Google SRE do przygotowania na rozmowę?

Bardzo ważna. Definiuje koncepcje, które większość rozmów SRE testuje [2].

Czy potrzebuję doświadczenia dyżurnego, aby uzyskać rolę SRE?

Preferowane, ale nie zawsze wymagane na stanowiskach początkujących.

Jakie certyfikaty są przydatne na rozmowach SRE?

Google Cloud Professional Cloud DevOps Engineer, AWS DevOps Engineer Professional i CKA są najbardziej odpowiednie.

Czym różni się rozmowa SRE od rozmowy na stanowisko inżyniera oprogramowania?

Rozmowy SRE obejmują projektowanie systemów z jawnymi ograniczeniami niezawodności, rundy rozwiązywania problemów i pytania behawioralne o zarządzanie incydentami [3].