Azure, które zespół prowadzi beze mnie.

• Essential

  • Tygodnie 1 i 2: rozpoznanie, mapowanie wymagań regulacyjnych, podpisany zestaw ADR
  • Tygodnie od 3 do 6: landing zone i biblioteka Terraform wdrożone, przez nie przechodzi pilotażowe obciążenie
  • Topologia startowa: grupa główna i dziewięć grup z szablonu, od 3 do 5 subskrypcji
  • Podstawa Entra ID i PIM (PIM wymaga Entra ID P2 albo Entra ID Governance), polityki CIS i tagowania
  • 10 runbooków platformy i 30-dniowe okno na pytania po przekazaniu

  Uporządkowane środowisko Azure, które prowadzi Państwa zespół, z decyzjami projektowymi zapisanymi na piśmie.

• Operate

  • Wszystko z poziomu Essential
  • Skany dryfu konfiguracji w harmonogramie uzgodnionym przy ustalaniu zakresu; ustalenia trafiają jako pull requesty
  • Miesięczny przegląd platformy: dryf konfiguracji, wyniki Azure Policy, koszty w podziale na właścicieli
  • Kwartalny przegląd Azure Policy i RBAC z dostrojeniem Defender for Cloud
  • Miesięcznie: 10 godz. na zmiany, przeglądy i pytania o to, co wdrożyłem albo przejrzałem. Niewykorzystane godziny nie przechodzą na kolejny miesiąc. Bez obiecanego czasu reakcji. Faktura co miesiąc z góry. Bez okresu minimalnego, 30-dniowy okres wypowiedzenia dla obu stron.

  Środowisko pozostaje takie, jak zaprojektowano. Państwa audytor może prześledzić każdą zmianę wdrożoną przez pipeline do zatwierdzonego pull requestu, a zmiana spoza pipeline wraca jako ustalenie z pull requestem.

• Topologia pul hostów i model pojemności
• Pipeline obrazów (Packer albo Azure VM Image Builder oraz Azure Compute Gallery)
• Wdrożenie profili FSLogix i kontenerów Office
• Autoskalowanie ze zmierzoną krzywą kosztów
• Dostarczanie aplikacji: App Attach (pakiety MSIX albo Appx), FSLogix App Masking albo instalacja na obrazie, według inwentarza

Terraform jest domyślny i jedyny, w którym dostarczam zestaw. Bicep, CDK albo Pulumi są możliwe tam, gdzie Państwa zespół już w nich pracuje, w osobnym zakresie.

Dokumenty zestawu (w tym runbooki i Exit Kit) oraz nazwy plików są na razie po angielsku. Po polsku jest zakres prac, który obie strony podpisują. Warunki umowy, Terms of Service, są po angielsku.

Proszę zacząć od mniejszego. Poziom Essential obejmuje startową landing zone: grupę główną i dziewięć grup z szablonu oraz od 3 do 5 subskrypcji. Pełne środowisko ma zwykle od 5 do 15 subskrypcji. Istniejące subskrypcje zostają tam, gdzie są, aż do zaplanowanej fali, która je przeniesie.

Do czytania, pulpitów i diagnostyki: tak. Produkcji nie zmienia się z portalu: nikt nie ma stałej roli z prawem zapisu, PIM nadaje ją na czas, a ręczna zmiana jest dryfem, który wraca do kodu (RUNBOOK-08). Na prawdziwe awarie jest udokumentowana ścieżka break-glass. Subskrypcje sandbox zostają otwarte na eksperymenty, więc zabezpieczenia chronią produkcję, nie spowalniając niczyjej nauki.

Państwa pracownicy. Recenzenci repozytorium i osoby zatwierdzające w PIM są od pierwszego dnia wskazanymi rolami po Państwa stronie, a ja zgłaszam pull requesty jak wszyscy. Na poziomie Operate też recenzuję, a prawo zatwierdzenia zostaje u Państwa pracowników.

Warstwa zarządzania (grupy zarządzania, polityki, RBAC) nic nie kosztuje. Koszt bieżący generują sieć hub (Azure Firewall i bramy), retencja logów oraz płatny plan Defender for Cloud, który włącza zestaw, bo Defender for Cloud pokazuje standard CIS tylko przy płatnym planie. Rozmiar i cenę każdej z tych pozycji ustalam w fazie projektu, zanim cokolwiek zostanie wdrożone. Jeśli SKU Azure Firewall jest dla Państwa środowiska za duże, projekt to wskaże.

Normą jest środowisko już istniejące (brownfield). Istniejące subskrypcje inwentaryzuję w rozpoznaniu, importuję do stanu Terraform albo przenoszę w zaplanowanych falach, a nic nie jest przenoszone, zanim właściciel zasobu pozna termin okna serwisowego.

Zostaje u Państwa: od pierwszego commita kod jest w Państwa organizacji GitHub, a stan na Państwa koncie storage. Opłacone rezultaty, w tym ten kod, mogą Państwo bezterminowo używać i zmieniać w swojej organizacji oraz przekazać innemu dostawcy (Terms of Service, sekcja 6). Exit Kit dodaje procedurę przekazania stanu, odebranie mojego dostępu i listę wszystkiego, co niedokończone. Dotyczy to każdego poziomu.

To różne problemy. Windows 365: prosty, rozliczany za użytkownika, mało elastyczny. AVD: gęstszy i tańszy w dużej skali, ale wymaga więcej pracy operacyjnej.

Prawie zawsze z jednego z dwóch powodów: hosty dobrano do liczby pracowników zamiast do zmierzonej liczby jednoczesnych użytkowników albo autoskalowania nigdy nie włączono, bo nikt nie ufał mu przy aktywnych sesjach. Poprawiam oba: model pojemności dobiera rozmiar do szczytu jednoczesnych użytkowników, a plan skalowania wyłącza hosty dopiero wtedy, gdy nie ma na nich aktywnych sesji.

Dla praw dostępu do Windows 11 Enterprise multi-session: tak, te licencje je zawierają (potwierdzam to w rozpoznaniu, według aktualnych warunków Microsoft). Dodatkowo płacą Państwo za zasoby obliczeniowe i storage Azure, a tę część trzymają w ryzach model pojemności i autoskalowanie.

To jeden z głównych powodów, dla których warto uruchomić AVD. Zewnętrzni współpracownicy dostają dostęp przez przeglądarkę wyłącznie do opublikowanych aplikacji: bez instalacji klienta, bez przekierowania dysków i schowka, z dostępem, który domyślnie wygasa w dniu zakończenia projektu. Proces nadawania dostępu zewnętrznym współpracownikom jest częścią runbooków wdrożenia AVD. Każdy współpracownik potrzebuje licencji uprawniającej do AVD (na przykład Microsoft 365 E3 albo Business Premium), przypisanej do jego konta w Państwa tenancie; licencja z jego własnej firmy zwykle tu nie wystarcza.