Administracja chmurą

Co się dzieje z chmurą bez administratora

Chmura nie wymaga wymiany dysków ani wizyty w serwerowni, więc łatwo uwierzyć, że nie wymaga też opieki. Po roku wygląda to zwykle tak: kilkanaście zasobów, o których nikt nie pamięta, dwa środowiska testowe pracujące całą dobę, konto administratora bez drugiego składnika logowania i rachunek, którego nikt nie potrafi rozbić na działy.

Praca, która zniknęła razem ze sprzętem, nie zniknęła w całości. Zmieniła miejsce.

Rachunek, który rośnie sam

Trzy najczęstsze przyczyny, jakie widzimy przy przejmowaniu środowisk:

• Zasoby zapomniane. Maszyna uruchomiona na potrzeby testu sprzed roku, dysk po skasowanej maszynie, adres IP zarezerwowany i nieużywany.
• Zły dobór rozmiaru. Maszyna dobrana na oko, zwykle o klasę za duża, bo przy uruchomieniu nikt nie mierzył obciążenia.
• Brak harmonogramu. Środowiska deweloperskie pracujące w nocy i w weekendy, choć korzysta z nich pięć osób w godzinach pracy.

Wszystkie trzy są proste do usunięcia, o ile ktoś patrzy na rachunek częściej niż raz na kwartał.

Tożsamość jest ważniejsza niż sieć

W środowisku lokalnym granicą jest firewall. W chmurze granicą jest konto. Dlatego pierwszą rzeczą, którą porządkujemy po przejęciu subskrypcji, jest logowanie: wieloskładnikowe uwierzytelnianie dla wszystkich, role zamiast uprawnień właściciela dla każdego, dostęp administracyjny nadawany na czas zadania i rejestrowanie logowań z nietypowych miejsc.

Przejęte konto administratora chmury oznacza dostęp do wszystkiego naraz, łącznie z kopiami. To jedyny scenariusz, w którym firma traci dane i kopie tego samego dnia.

Co monitorujemy

Obszar	Co sprawdzamy	Reakcja
Koszty	dzienne zużycie wobec budżetu	alert przy przekroczeniu progu
Tożsamość	logowania nietypowe, konta bez MFA	zgłoszenie tego samego dnia
Maszyny	dostępność, zasoby, aktualizacje	jak przy serwerach lokalnych
Kopie	wykonanie zadania i test odtworzenia	zgłoszenie przy błędzie
Certyfikaty i domeny	terminy wygaśnięcia	ostrzeżenie 30 dni wcześniej
Uprawnienia	przegląd ról	raz na kwartał, z listą do zatwierdzenia

Terraform zamiast klikania w panelu

Środowisko, które powstało klikaniem, ma zwykle jedną wspólną cechę: nikt nie potrafi go odtworzyć. My prowadzimy je kodem, bo wtedy zmiana przechodzi przez plan pokazujący, co dokładnie się wydarzy, a odtworzenie sieci czy uprawnień po pomyłce trwa kilkanaście minut zamiast dnia.

Praktyka wygląda tak: moduły na powtarzalne elementy, stan trzymany zdalnie z blokadą, sekrety poza repozytorium, zmiany wykonywane przez potok CI/CD po zatwierdzeniu. Panel zostaje jako dostęp awaryjny. Szerzej opisaliśmy to przy Terraformie.

Której chmury używamy najczęściej

Prowadzimy AWS, Google Cloud i Azure, ale przy nowych projektach domyślnie proponujemy dwie pierwsze. Powód jest praktyczny, nie ideologiczny: model uprawnień i sieci jest tam bliższy temu, co znamy z infrastruktury lokalnej, narzędzia wiersza poleceń są wygodniejsze w automatyzacji, a rachunek łatwiej rozbić na projekty.

Azure proponujemy wtedy, gdy firma pracuje na Microsoft 365 i Active Directory, bo wspólna tożsamość i jedno logowanie są warte więcej niż różnice między platformami. To jedyne kryterium, jakie tu stosujemy.

Kiedy chmura przestaje się opłacać

Gdy przenieśliście do niej maszynę pracującą całą dobę pod stałym obciążeniem, gdy płacicie za transfer danych między chmurą a biurem przy każdej operacji albo gdy kupiliście moc na szczyt, który zdarza się raz w roku.

W takich przypadkach mówimy wprost, że część środowiska warto wrócić na własny sprzęt albo do kolokacji, i pokazujemy rachunek dla obu wariantów. Model mieszany opisaliśmy przy chmurze hybrydowej.

Treść sprawdzona i zaktualizowana: 30 lipca 2026