AWS rośnie. Państwa kontrola musi rosnąć razem z nim.

Pilotaż powstaje często pod presją czasu i z ograniczoną liczbą użytkowników. Gdy jednak dołączają kolejne zespoły, nieformalne ustalenia przestają wystarczać. Zasoby muszą zostać przypisane, uprawnienia administracyjne zweryfikowane, a usługi wspólne odpowiednio uporządkowane. Inwentaryzacja obejmuje więc istniejące konta wraz z projektami i osobami, które za nimi stoją. Dzięki temu widać, które struktury zostały wybrane świadomie, które miały charakter tymczasowy i jakie zmiany są rzeczywiście niezbędne przed większą rozbudową.

Model docelowy opisuje, jak dołączane są nowe zespoły i jakie zasady mają obowiązywać dla istniejących kont. Uwzględnia się przy tym zakresy odpowiedzialności, miejsca powstawania kosztów oraz rozdzielenie różnych środowisk. Wdrożenie odbywa się w uzgodnionych etapach, aby uwzględnić działające aplikacje i istniejące zależności. Pierwszy konkretny przypadek użycia służy jako weryfikacja nowych procedur. Następnie Państwa zespół może ocenić, czy wdrażanie, zatwierdzenia i dokumentacja działają w sposób zrozumiały również poza pierwotnym zespołem pilotażowym.

Docelowe środowisko aplikacji składa się często z wielu komponentów o różnych wymaganiach. Moc obliczeniową, przechowywanie danych, interfejsy i dostępy administracyjne trzeba rozpatrywać łącznie. Razem z Państwem porównujemy odpowiednie warianty struktury i uwzględniamy przyszły nakład na eksploatację. Istotne pozostają przy tym również dostępne kompetencje: przewidziane zespoły muszą być w stanie rozwiązanie zrozumieć, monitorować i zmieniać. Zakres modernizacji jest więc świadomie oddzielany od zadań, które są najpierw niezbędne do bezpiecznego przejścia.

Na potrzeby realizacji dokumentowane są zależności i weryfikacje. Zespoły aplikacyjne potwierdzają poprawność działania pod względem merytorycznym, a testy techniczne obejmują dostępy, połączenia i uzgodnioną strukturę eksploatacji. Jeśli lokalne systemy są wciąż potrzebne, ich drogi komunikacji wchodzą w zakres odbioru. Przekazanie opisuje również, jak po zakończeniu projektu wprowadzane są zmiany i jaka dokumentacja jest do tego dostępna. W ten sposób dodatkowe obciążenie robocze można włączyć do środowiska AWS, nie pozostawiając po zakończeniu migracji niejasnej odpowiedzialności.

Rosnący rachunek może mieć bardzo różne przyczyny: nowe aplikacje, zmienione użycie, przewymiarowane zasoby lub środowiska działające dłużej niż potrzeba. Sam przegląd kosztów nie pokazuje jeszcze, jaka zmiana techniczna byłaby sensowna. Dlatego wydatki łączymy z użyciem i odpowiedzialnością. W rozmowie z zespołami aplikacyjnymi wyjaśniamy, które rezerwy są świadomie przewidziane, a gdzie faktycznie widać zużycie, którego można uniknąć. Działania powstają w ten sposób na podstawie kontekstu aplikacji.

Przed wprowadzeniem zmiany uzgadniane są możliwe skutki oraz niezbędna weryfikacja. Po realizacji analizujemy obserwowane użycie i wpływ na eksploatację. Nie każde technicznie możliwe ograniczenie jest odpowiednie dla każdego obciążenia roboczego. Dokumentacja rejestruje więc założenia i decyzje, aby dalsze optymalizacje mogły do nich nawiązywać. Dla bieżącej obsługi określane są dodatkowo ścieżki zgłaszania, utrzymanie i zakresy odpowiedzialności, dzięki czemu decyzje kosztowe pozostają związane z faktyczną odpowiedzialnością za systemy.