Microsoft Azure z OTOKO®

Azure pod kontrolą.

Microsoft Azure ma obsługiwać Państwa aplikacje, umożliwiać nowe projekty i wpisywać się w istniejące środowisko Microsoft. Do tego potrzeba czegoś więcej niż pojedynczych wykupionych usług. OTOKO® łączy budowę platformy, migrację i eksploatację z przejrzystym planowaniem kosztów i umów: od uprawnień użytkowników i sieci po pytanie, czy zobowiązanie (commitment) jest opłacalne przy Państwa rzeczywistym zużyciu.

Czym się dla Państwa zajmujemy

Microsoft Azure

Planowanie, realizacja i uzgodniona eksploatacja przez OTOKO®

Zdjęcie ilustracyjne · nie jest to zdjęcie lokalizacji dostawcy

Państwa zlecenie dla OTOKO®

Z pojedynczych projektów Azure powstaje wspólna platforma.

Dział biznesowy potrzebuje w krótkim czasie nowego środowiska, podczas gdy IT wciąż uzgadnia dostępy, sieci i budżety. Równolegle działają już aplikacje w różnie skonfigurowanych subskrypcjach. Właśnie w tym miejscu zaczynamy: inwentaryzujemy to, co już istnieje, ustalamy wspólne reguły i wdrażamy kolejne aplikacje na solidnej podstawie.

Co mogą Państwo nam zlecić

Zakres zlecenia zależy od Państwa punktu wyjścia: uporządkowania istniejącego środowiska Azure, zbudowania Landing Zone albo migracji aplikacji wraz z przekazaniem. Do realizacji należą konfiguracja, testy i dokumentacja. Dla późniejszej opieki systemy i zakres usług są ustalane odrębnie; kwestie zakupowe rozpatrujemy wspólnie z Państwa planowaniem technicznym.

Szczegóły usług

Zakres usługi

Budowa, integracja i ekonomiczna eksploatacja Azure.

Moduły obejmują zakres od wspólnej podstawy platformy po analizę umów. Punktem wyjścia może być nowa aplikacja lub istniejące środowisko; kolejność wyznaczają zależności techniczne i pożądany zakres opieki.

Konfiguracja Azure dla Państwa zespołów

Nowe projekty potrzebują zdefiniowanego miejsca w Państwa środowisku Azure. W tym celu porządkujemy subskrypcje, rozdzielamy testy od produkcji oraz przypisujemy uprawnienia i miejsca powstawania kosztów (MPK). Konfiguracje wielokrotnego użytku pomagają Państwa zespołowi budować kolejne środowiska według tych samych reguł. Istniejące zasoby są sprawdzane pod kątem włączenia do tej struktury.

Na tej podstawie Państwa zespół pracuje dalej

Wersjonowana Landing Zone z modelem ról, politykami i udokumentowaną ścieżką tworzenia nowych subskrypcji.

Realizacja techniczna

Azure Landing Zone i governance

Grupy zarządzania, subskrypcje i grupy zasobów porządkują Państwa środowisko Azure. Definiujemy rozdzielenie środowisk deweloperskich i produkcyjnych, role za pomocą Azure RBAC oraz reguły za pomocą Azure Policy. Nazewnictwo, tagi i budżety są uzgadniane z osobami odpowiedzialnymi. Terraform lub Bicep odwzorowują uzgodnioną podstawę jako Infrastructure as Code.

Połączenie Państwa istniejącej infrastruktury IT z Azure

Konta użytkowników, rozpoznawanie nazw i ścieżki sieciowe muszą do siebie pasować w chmurze i w centrum danych. Podłączenie planujemy na podstawie Państwa aplikacji i ich ścieżek komunikacji. Następnie konfigurujemy i testujemy dostępy oraz połączenia, sprawdzając również, których procesów biznesowych dotyczyłaby ewentualna przerwa.

Na tej podstawie Państwa zespół pracuje dalej

Koncepcja dostępu i sieci z udokumentowanymi połączeniami oraz testami niezbędnych ścieżek danych.

Realizacja techniczna

Microsoft Entra ID i sieci hybrydowe

Tożsamości i dostępy sieciowe są analizowane wspólnie: istniejące Active Directory, Microsoft Entra ID, role administracyjne, DNS i segmentacja sieci. Dla połączenia z centrum danych oceniamy Site-to-Site VPN lub ExpressRoute. Routing, rozpoznawanie nazw i scenariusze awarii są wyjaśniane przed migracją.

Przeniesienie serwerów i aplikacji do Azure

Nie każdą aplikację przenosi się w ten sam sposób. Wspólnie z osobami odpowiedzialnymi po Państwa stronie sprawdzamy serwery, bazy danych i interfejsy, wybieramy odpowiednie środowisko docelowe i łączymy powiązane systemy w fale migracji. Testy biznesowe, uzgodnione przełączenie i przekazanie do eksploatacji są częścią tego samego przedsięwzięcia.

Na tej podstawie Państwa zespół pracuje dalej

Ocena obciążeń, plan migracji oraz uzgodnione odbiory przeniesionych aplikacji.

Realizacja techniczna

Migracja do Azure i modernizacja aplikacji

Oceniamy maszyny wirtualne, bazy danych i interfejsy oraz planujemy fale migracji. Azure Migrate może wspierać ocenę stanu bieżącego. Dla modelu docelowego porównujemy Azure Virtual Machines, App Service i Azure Kubernetes Service (AKS) w odniesieniu do Państwa aplikacji. Testy merytoryczne i opcje wycofania towarzyszą przełączeniu.

Organizacja codziennej eksploatacji

Alarm pomaga tylko wtedy, gdy ktoś wie, jak na niego zareagować. Dla Państwa systemów Azure dostosowujemy monitorowanie, ścieżki zgłaszania, kopie zapasowe i przywracanie do wymagań eksploatacyjnych. W ten sposób powstają zdefiniowane zadania dla Państwa zespołu oraz dla opieki, którą przejmujemy.

Na tej podstawie Państwa zespół pracuje dalej

Koncepcja eksploatacji i przywracania danych z uwzględnieniem ścieżek alarmowania, zakresu kopii zapasowych i uzgodnionych testów przywracania.

Realizacja techniczna

Bezpieczeństwo, monitoring i przywracanie danych w Azure

Azure Monitor i Log Analytics wspierają obserwację Państwa środowiska, a Microsoft Defender for Cloud może dostarczać dodatkowe oceny bezpieczeństwa. Określamy, które komunikaty są obsługiwane, kto na nie reaguje i jaki okres przechowywania jest potrzebny. Azure Backup oraz, w razie potrzeby, Azure Site Recovery są oceniane względem celów przywrócenia działania Państwa aplikacji.

Przejrzystość wydatków na chmurę

Która aplikacja powoduje rosnący rachunek? Oznaczenia kosztowe i dane o wykorzystaniu umożliwiają przypisanie wydatków do konkretnych zespołów i systemów. Na tej podstawie sprawdzamy nieużywane zasoby, odpowiednie rozmiary i okresy działania. Zmiany są priorytetyzowane wspólnie z osobami odpowiedzialnymi i weryfikowane na podstawie rzeczywistego zużycia.

Na tej podstawie Państwa zespół pracuje dalej

Baza kosztów z przypisanymi wydatkami oraz plan działań z ustalonymi priorytetami, osobami odpowiedzialnymi i założeniami, które można zweryfikować.

Realizacja techniczna

Azure FinOps i przejrzystość zużycia

Za pomocą oznaczania kosztów, Azure Cost Management i technicznych danych o wykorzystaniu przypisujemy wydatki do zespołów i aplikacji. Najpierw analizowane są dopasowanie rozmiaru zasobów (rightsizing), niepotrzebne zasoby i środowiska deweloperskie działające według harmonogramu. Dopiero na tej podstawie oceniamy Reservations lub Azure Savings Plans, aby zobowiązanie nie utrwalało niepotrzebnego zużycia.

Weryfikacja umów i warunków Azure

Korzystna stawka jest opłacalna tylko wtedy, gdy zobowiązanie odpowiada potrzebom. Dlatego istniejące umowy, przewidywane zużycie i możliwe programy są oceniane łącznie. Nasze porównanie jasno przedstawia warunki, okresy obowiązywania i sposób rozliczania; rabaty lub refundacje są uwzględniane na podstawie konkretnie potwierdzonych warunków.

Na tej podstawie Państwa zespół pracuje dalej

Przejrzyste porównanie ofert obejmujące okres obowiązywania, zobowiązanie, kwalifikowalność, rozliczenia oraz pisemnie potwierdzone warunki.

Realizacja techniczna

Zakup Azure, zobowiązania (commitments) i warunki

Analizujemy Państwa obecną umowę i sposób zakupu, na przykład CSP lub bezpośrednią umowę z Microsoft. Microsoft Azure Consumption Commitment (MACC), Reservations i Savings Plans to różne instrumenty. Możliwe rabaty, dotacje lub refundacje sprawdzamy na podstawie konkretnego programu i oferty, ponieważ nie wynikają one automatycznie z samego zobowiązania.

Planowanie i realizacja w szczegółach

Azure w firmie: co należy wyjaśnić przed rozbudową.

Środowisko Azure rozwija się wraz z wymaganiami działów biznesowych. Aby powstała z niego spójna platforma, architekturę, organizację eksploatacji i zakupy należy planować wspólnie. Nad tymi decyzjami pracujemy z Państwa IT oraz osobami odpowiedzialnymi za poszczególne aplikacje.

Sensowne uwzględnienie istniejących struktur Microsoft

Wiele firm nie zaczyna od zera: konta użytkowników już istnieją, poszczególne zespoły korzystają z Azure, a lokalne aplikacje sięgają do wewnętrznych usług katalogowych lub plikowych. Przed rozbudową sprawdzamy więc, jakie tożsamości, subskrypcje i połączenia sieciowe są faktycznie wykorzystywane. Interesuje nas przy tym nie tylko konfiguracja, ale również jej pochodzenie: kto wprowadził wyjątek, która aplikacja go wymaga i kto może decydować o zmianie? Taka inwentaryzacja zapobiega sytuacji, w której nowy model docelowy niepostrzeżenie przerywa działające procesy biznesowe.

Na podstawie stanu bieżącego opracowujemy strukturę, w której zakresy odpowiedzialności i granice techniczne są ze sobą zgodne. Środowiska deweloperskie i produkcyjne są od siebie oddzielone w niezbędnym zakresie, a zadania administracyjne przypisujemy odpowiednim rolom. Wspólnie ustalamy również, jak kolejny zespół składa wniosek o środowisko i kto zatwierdza koszty oraz dostępy. Przyjęcie pierwszego projektu na platformę służy jako praktyczny test. Państwa zespół otrzymuje dzięki temu nie tylko schemat architektury, lecz również przejrzysty sposób korzystania z platformy w codziennej pracy, a później jej samodzielnego rozwijania.

Planowanie aplikacji z uwzględnieniem ich przyszłej eksploatacji

Przy przeniesieniu aplikacji nie wystarczy pytanie o odpowiednią maszynę wirtualną. Należy uwzględnić bazy danych, mechanizmy logowania, zewnętrzne interfejsy, zadania w tle oraz dostępność z sieci firmowej. Wspólnie analizujemy, które komponenty można przejąć bez zmian, a gdzie dostosowanie jest sensowne lub niezbędne. Decyzję podejmujemy, ważąc nakład związany z przejściem, zadania eksploatacyjne i dostępne kompetencje. Technicznie możliwa modernizacja nie musi automatycznie stanowić części pierwszej fali migracji.

Już na etapie planowania docelowego przypisujemy odpowiedzialność za monitoring, kopie zapasowe i przywracanie. Które komunikaty są istotne dla eksploatacji? Kto sprawdza działanie po aktualizacji? Które dane muszą być ze sobą spójne po przywróceniu? Takie pytania trafiają do planu testów i przekazania. Reprezentatywne obciążenie robocze (workload) pomaga przetestować procedury przed kolejnymi przeniesieniami. Dopiero wspólna ocena strony technicznej i funkcji biznesowej pokazuje, czy podstawa jest gotowa na kolejne aplikacje.

Zestawienie zobowiązań (commitments) ze zużyciem i planami zmian

Decyzja dotycząca umowy wpływa na Państwa koszty na dłużej niż tylko następny miesiąc rozliczeniowy. Dlatego analizujemy istniejące modele zakupu i zobowiązania razem z planowanym wykorzystaniem platformy. Kończący się projekt, modernizacja aplikacji lub zmieniony okres eksploatacji mogą znacząco zmienić potrzeby. Dane o zużyciu interpretujemy w tym kontekście, zamiast po prostu ekstrapolować dawne szczyty obciążenia. Optymalizacje techniczne powinny być widoczne, zanim oceni się długoterminowe zobowiązanie na podstawie dzisiejszego zużycia.

Porównanie jasno pokazuje okres obowiązywania, warunki, rozliczenia i to, na ile przyjęte założenia dotyczące wykorzystania są realistyczne. Zobowiązania (commitments), rezerwacje (Reservations) i plany oszczędności (Savings Plans) traktujemy jako odrębne opcje, a nie jako wymienne obietnice rabatowe. Możliwe dotacje lub refundacje uwzględniamy wyłącznie na podstawie konkretnych warunków programu i potwierdzonych ofert. Dzięki temu Państwa decyzja pozostaje możliwa do zweryfikowania: zakupy i IT widzą, jakie założenia leżą u jej podstaw, jakie zobowiązanie powstaje i jakie zmiany należy jeszcze wyjaśnić przed jego zaciągnięciem.

Jak współpracujemy

Państwo znają swoją działalność.
My wykonujemy uzgodnione prace w chmurze.

Nie muszą Państwo samodzielnie organizować każdego technicznego kroku. Dokumentujemy zadania i decyzje oraz włączamy Państwa zespół tam, gdzie potrzebna jest jego wiedza lub zatwierdzenie.

Rozpoznanie dzierżawy (tenant) i przedsięwzięcia

Istniejące subskrypcje, połączenia i umowy pokazują, jakie podstawy już istnieją. Na tej podstawie wyznaczamy zakres budowy lub dalszego rozwoju.

Państwa wkład: Proszę wskazać aplikacje, których to dotyczy, osoby odpowiedzialne za dzierżawę oraz planowane zmiany.

Sprawdzenie środowiska docelowego w praktyce

Na wybranej aplikacji sprawdzane są konfiguracja, dostępy i ścieżki danych. Kolejne środowiska powstają dopiero po wspólnej ocenie.

Państwa wkład: Państwa zespół aplikacyjny sprawdza procesy biznesowe i zatwierdza kolejne kroki.

Przypisanie eksploatacji i kosztów

Konfiguracja i zadania eksploatacyjne zostają przekazane. Miejsca powstawania kosztów (MPK) i ścieżki zgłaszania pokazują, kto odpowiada za bieżące środowisko.

Państwa wkład: Proszę potwierdzić osoby odpowiedzialne za eksploatację, budżet i dalsze zatwierdzenia.

Przykładowy scenariusz projektu

Uporządkowanie rozrośniętego środowiska Azure

Tak mogłoby wyglądać wspólne przedsięwzięcie. Konkretny zakres wynika z Państwa sytuacji wyjściowej.

Sytuacja wyjściowa
Kilka zespołów już korzysta z Azure. Dostępy, połączenia sieciowe i rozliczenia podlegają różnym regułom.
Nasze podejście
Oceniamy środowisko, definiujemy wspólną strukturę docelową i stopniowo przenosimy do niej aplikacje.
Model docelowy
Przejrzysta platforma z jasnym podziałem odpowiedzialności i przeglądem kosztów, na której kolejne projekty mogą startować w zaplanowany sposób.

Co Państwo otrzymują

Rezultaty, na których
Państwa zespół może dalej pracować.

Docelowa architektura Azure z koncepcją kont, sieci i uprawnień
Plan realizacji z migracją, testami i odbiorem
Udokumentowana eksploatacja z zakresami odpowiedzialności i przeglądem kosztów

Planowanie Azure w wymiarze technicznym i ekonomicznym

Sprawdzamy Commitments, rabaty
i refundacje.

Ewentualna zniżka musi odpowiadać Państwa rzeczywistym potrzebom. Wspólnie z Państwem sprawdzamy model zakupu, zużycie i zobowiązania umowne, zanim podejmą Państwo wiążącą decyzję.

Zrozumienie zużycia
Łączna analiza istniejących kosztów, przewidywanego wykorzystania i planowanych zmian.
Sprawdzenie możliwości
Sprawdzenie odpowiednich programów i modeli zakupu pod kątem kwalifikowalności, umowy i okresu obowiązywania.
Zrozumienie warunków
Dokumentowanie rabatu lub refundacji, rozliczenia, zobowiązań i warunków w konkretnej ofercie.

Czy i w jakiej wysokości dostępne są korzyści, zależy od danego programu i Państwa oferty. Obowiązują uzgodnione w nich warunki.

Omówmy warunki Azure

Od zainteresowania do konkretnego zlecenia

Jak przygotowujemy
Państwa projekt.

Do pierwszej konsultacji te dokumenty nie muszą być jeszcze kompletne. Wspólnie ustalamy, co jest już dostępne i jakie informacje ma uzupełnić ocena.

Przydatne na początek

Struktura dzierżawy (tenant) i subskrypcji oraz dostępne osoby kontaktowe
Lista obciążeń, lokalizacje i najważniejsze zależności
Eksporty danych o kosztach, istniejące umowy i przewidywane zmiany potrzeb

Jak powstaje konkretna oferta

Zakres usług, zaangażowanie Państwa zespołu, potrzebne dostępy, kryteria odbioru i przekazanie są ujęte w ofercie. Opłaty dostawcy, usługi projektowe i bieżąca eksploatacja są rozdzielone w przejrzysty sposób.

Omówmy ocenę

Przed rozpoczęciem

Państwa pytania.
Jasne odpowiedzi.

Jak OTOKO® wspiera Państwa w kwestii zobowiązań Azure (commitments), rabatów i refundacji?

Wspólnie z Państwem analizujemy zużycie, istniejące umowy, planowane okresy obowiązywania i odpowiednie modele zakupu. To, czy w grę wchodzi zobowiązanie (commitment), rabat czy refundacja, zależy od danego programu, spełnienia przez Państwa jego warunków i konkretnej oferty. Warunki, okresy związania i rozliczenia wyjaśniamy pisemnie przed podjęciem decyzji.

Jakie usługi oferuje OTOKO® w zakresie Microsoft Azure?

Planowanie Azure, migracja aplikacji i dalszy rozwój eksploatacji. OTOKO® łączy realizację techniczną z analizą Państwa możliwości kosztowych i zakupowych.

Czy chmurę można połączyć z naszym centrum danych?

Tak. Architekturę hybrydową planujemy na podstawie Państwa interfejsów, tożsamości, sieci oraz wymagań dotyczących dostępności i lokalizacji danych.

Jaka jest różnica między MACC, Reservations i Savings Plans?

MACC oznacza umowne zobowiązanie wobec Microsoft do określonego poziomu zużycia. Reservations odnoszą się do konkretnych kwalifikujących się zasobów, natomiast w ramach Savings Plan zobowiązują się Państwo do uzgodnionej kwoty godzinowej za kwalifikujące się wykorzystanie. Zastosowanie i warunki są sprawdzane odrębnie. Żaden z tych modeli nie jest ryczałtową refundacją.

Czy nasze istniejące środowisko Microsoft może być dalej wykorzystywane?

Tak. Przed wprowadzeniem zmian sprawdzamy dzierżawę (tenant), tożsamości, subskrypcje i zależności. Istniejące wykorzystanie Microsoft 365 nie zastępuje jednak ani koncepcji architektury Azure, ani weryfikacji wymaganych licencji i uprawnień.

Czy Azure można połączyć z Telekom T Cloud lub własnym centrum danych?

Architektura hybrydowa lub multi-cloud jest możliwa. Przy jej planowaniu wyraźnie uwzględniamy przepływy danych, połączenia sieciowe, tożsamości i zakresy odpowiedzialności. Do decyzji należą również transfer danych, opóźnienia oraz dodatkowa złożoność eksploatacyjna.

Jaki rabat lub jaką refundację otrzymamy?

Bez wcześniejszej analizy nie da się rzetelnie podać konkretnej wartości. Decydujące znaczenie mają model zakupu, kwalifikujące się zużycie, okres obowiązywania i reguły programu. Przyznane korzyści i warunki dokumentujemy w ofercie, a planowane oszczędności nie są przedstawiane jako gwarantowany wynik.

Microsoft Azure z OTOKO®

Gdzie Państwa środowisko Azure dziś spowalnia pracę?

Zacznijmy od konkretnego przedsięwzięcia: nadchodzącej migracji, nieprzejrzystych subskrypcji lub kolejnej decyzji dotyczącej umowy. Wspólnie określimy zakres zadania i wyjaśnimy, jakich danych o zasobach i zużyciu brakuje do przygotowania wiarygodnej oferty.

Umów pierwszą konsultację: Microsoft Azure

Menu

Azure pod kontrolą.