Udostępnij za pośrednictwem


Kompromisy w optymalizacji kosztów

Podczas projektowania obciążenia w celu zmaksymalizowania zwrotu z inwestycji (ROI) w ramach ograniczeń finansowych należy najpierw wyraźnie zdefiniować wymagania funkcjonalne i niefunkcjonalne. Strategia priorytetyzacji pracy i nakładu pracy jest niezbędna. Fundacja jest zespołem, który ma silne poczucie odpowiedzialności finansowej. Zespół powinien mieć silną wiedzę na temat dostępnych technologii i modeli rozliczeń.

Po zrozumieniu zwrotu z inwestycji w obciążenie możesz zacząć go ulepszać. Aby ulepszyć zwrot z inwestycji, rozważ, w jaki sposób decyzje oparte na zasadach projektowania optymalizacji kosztów i zalecenia z listy kontrolnej przeglądu projektu dla optymalizacji kosztów mogą mieć wpływ na cele i optymalizacje innych filarów platformy Azure Well-Architected Framework. W przypadku optymalizacji kosztów ważne jest, aby uniknąć skupienia się na tańszym rozwiązaniu. Wybory, które koncentrują się tylko na minimalizowaniu wydatków, mogą zwiększyć ryzyko podważania celów biznesowych i reputacji obciążenia. W tym artykule opisano przykładowe kompromisy, które zespół ds. obciążeń może napotkać podczas rozważania ustawienia docelowego, projektowania i operacji na potrzeby optymalizacji kosztów.

Kompromisy optymalizacji kosztów z niezawodnością

Koszt przerwy w działaniu usługi musi być mierzony względem kosztów zapobiegania lub odzyskiwania po jednej z nich. Jeśli koszt zakłóceń przekracza koszt projektowania niezawodności, należy zainwestować więcej, aby zapobiec lub ograniczyć zakłócenia. Z drugiej strony koszt wysiłków związanych z niezawodnością może być większy niż koszt zakłóceń, w tym czynniki, takie jak wymagania dotyczące zgodności i reputacja. Należy rozważyć strategiczne zbycie w projekcie niezawodności tylko w tym scenariuszu.

Kompromis: zmniejszona odporność. Obciążenie obejmuje środki odporności w celu uniknięcia i wytrzymania określonych typów i ilości awarii.

  • Aby zaoszczędzić pieniądze, zespół ds. obciążeń może aprowzować składnik lub nadmiernie ograniczyć jego skalowanie, dzięki czemu składnik może ulec awarii podczas nagłego wzrostu zapotrzebowania.

  • Konsolidowanie zasobów obciążeń (zwiększenie gęstości) na potrzeby optymalizacji kosztów sprawia, że poszczególne składniki mogą częściej pracować w przypadku skoków zapotrzebowania i podczas operacji konserwacji, takich jak aktualizacje.

  • Usuwanie składników obsługujących wzorce projektowe odporności, takie jak magistrala komunikatów, i tworzenie bezpośredniej zależności zmniejsza możliwości samodzielnego zachowywania.

  • Oszczędność pieniędzy dzięki zmniejszeniu nadmiarowości może ograniczyć zdolność obciążenia do obsługi współbieżnych awarii.

  • Użycie jednostek SKU budżetu może ograniczyć maksymalny cel poziomu usług (SLO), który może osiągnąć obciążenie.

  • Ustawienie limitów wydatków twardych może uniemożliwić skalowanie obciążenia w celu spełnienia uzasadnionego zapotrzebowania.

  • Bez narzędzi do testowania niezawodności lub testów niezawodność obciążenia jest nieznana i jest mniej prawdopodobne, aby spełnić cele dotyczące niezawodności.

Kompromis: Ograniczona strategia odzyskiwania. Obciążenie, które jest niezawodne, ma przetestowany plan reagowania na zdarzenia i odzyskiwania dla scenariuszy awarii.

  • Zmniejszenie testowania lub przechodzenia do szczegółów planu odzyskiwania po awarii obciążenia może mieć wpływ na szybkość i skuteczność operacji odzyskiwania.

  • Tworzenie lub przechowywanie mniejszej liczby kopii zapasowych zmniejsza możliwe punkty odzyskiwania i zwiększa prawdopodobieństwo utraty danych.

  • Wybranie tańszej umowy pomocy technicznej z partnerami technologicznymi może zwiększyć czas odzyskiwania obciążenia z powodu potencjalnych opóźnień w pomocy technicznej.

Kompromis: zwiększona złożoność. Obciążenie, które korzysta z prostych podejść i pozwala uniknąć niepotrzebnej lub nadmiernej złożoności, jest ogólnie łatwiejsze do zarządzania pod względem niezawodności.

  • Użycie wzorców chmury optymalizacji kosztów może dodawać nowe składniki, takie jak sieć dostarczania zawartości (CDN) lub przenosić obowiązki do urządzeń brzegowych i klienckich, dla których obciążenie musi zapewnić cele niezawodności.

  • Skalowanie oparte na zdarzeniach może być bardziej skomplikowane do dostosowania i zweryfikowania niż skalowanie oparte na zasobach.

  • Zmniejszenie ilości danych i obsługę warstw danych za pomocą akcji cyklu życia danych, ewentualnie w połączeniu z implementowaniem zagregowanych punktów danych przed zdarzeniem cyklu życia, wprowadza czynniki niezawodności do rozważenia w obciążeniu.

  • Optymalizowanie kosztów przy użyciu różnych regionów może utrudnić zarządzanie, sieć i monitorowanie.

Kompromisy optymalizacji kosztów z zabezpieczeniami

Koszt naruszenia poufności, integralności i dostępności w obciążeniu musi być zawsze zrównoważony względem kosztów nakładu pracy, aby zapobiec temu naruszeniu. Zdarzenie bezpieczeństwa może mieć szeroki zakres skutków finansowych i prawnych oraz zaszkodzić reputacji firmy. Inwestowanie w bezpieczeństwo jest działaniem zaradczym ryzyka. Koszt wystąpienia ryzyka musi być zrównoważony w stosunku do inwestycji. Z zasady nie należy naruszać zabezpieczeń w celu uzyskania optymalizacji kosztów, które są poniżej punktu odpowiedzialnego i uzgodnionego ograniczenia ryzyka. Optymalizowanie kosztów zabezpieczeń poprzez prawa do rozwiązań jest ważną praktyką optymalizacji, ale należy pamiętać o kompromisach, takich jak poniższe.

Kompromis: zmniejszona kontrola zabezpieczeń. Mechanizmy kontroli zabezpieczeń są ustanawiane w wielu warstwach, czasami nadmiarowo, aby zapewnić ochronę w głębi systemu.

Jedną z taktyki optymalizacji kosztów jest wyszukanie sposobów usuwania składników lub procesów, które naliczają koszty jednostkowe lub operacyjne. Usunięcie składników zabezpieczeń, takich jak w poniższych przykładach, ze względu na oszczędność pieniędzy wpływa na bezpieczeństwo. Należy dokładnie przeprowadzić analizę ryzyka na ten wpływ.

  • Zmniejszenie lub uproszczenie technik uwierzytelniania i autoryzacji narusza jawną zasadę weryfikacji architektury zerowej zaufania. Przykłady tych ułatwień obejmują użycie podstawowego schematu uwierzytelniania, takiego jak klucze wstępnie udostępniane, a nie inwestowanie czasu na poznanie branżowych podejść OAuth lub użycie uproszczonych przypisań kontroli dostępu opartej na rolach w celu zmniejszenia nakładu pracy związanego z zarządzaniem.

  • Usunięcie szyfrowania podczas przesyłania lub magazynowania w celu zmniejszenia kosztów certyfikatów i ich procesów operacyjnych uwidacznia dane potencjalnym naruszeniom integralności lub poufności.

  • Usunięcie lub zmniejszenie możliwości skanowania zabezpieczeń lub narzędzi do inspekcji lub testowania zabezpieczeń z powodu związanych z tym kosztów i inwestycji w czas może mieć bezpośredni wpływ na poufność, integralność lub dostępność, którą ma chronić narzędzia i testowanie.

  • Zmniejszenie częstotliwości stosowania poprawek zabezpieczeń ze względu na czas operacyjny zainwestowany w katalogowanie i stosowanie poprawek wpływa na zdolność obciążenia do rozwiązywania zmieniających się zagrożeń.

  • Usunięcie kontrolek sieciowych, takich jak zapory, może prowadzić do niepowodzenia blokowania złośliwego ruchu przychodzącego i wychodzącego.

Kompromis: zwiększony obszar powierzchni obciążenia. Filar zabezpieczeń określa priorytet ograniczony i zawarty obszar powierzchni, aby zminimalizować wektory ataków i zarządzanie mechanizmami kontroli zabezpieczeń.

Wzorce projektowe chmury, które optymalizują koszty, czasami wymagają wprowadzenia dodatkowych składników. Te dodatkowe składniki zwiększają obszar powierzchni obciążenia. Składniki i dane w nich muszą być zabezpieczone, prawdopodobnie w sposób, który nie jest jeszcze używany w systemie. Te składniki i dane często podlegają zgodności. Przykłady wzorców, które mogą wprowadzać składniki, to:

  • Używanie wzorca hostingu zawartości statycznej do odciążania danych do nowego składnika CDN.

  • Używanie wzorca klucza valet do odciążania przetwarzania i bezpiecznego dostępu do zasobów obliczeniowych klienta.

  • Korzystanie ze wzorca bilansowania obciążenia opartego na kolejce w celu złagodzenia kosztów przez wprowadzenie magistrali komunikatów.

Kompromis: Usunięto segmentację. Filar zabezpieczeń określa silną segmentację w celu zapewnienia obsługi stosowania docelowych mechanizmów kontroli zabezpieczeń i kontrolowania promienia wybuchu.

Udostępnianie zasobów, na przykład w sytuacjach wielodostępności lub współlokowanie wielu aplikacji na udostępnionej platformie aplikacji, jest podejściem do zmniejszenia kosztów poprzez zwiększenie gęstości i zmniejszenie powierzchni zarządzania. Ta zwiększona gęstość może prowadzić do problemów związanych z bezpieczeństwem, takich jak następujące:

  • Penetracja sieci między składnikami współużytkowymi jest łatwiejsza. Zdarzenie zabezpieczeń, które narusza dostępność hosta platformy aplikacji lub pojedynczej aplikacji, ma również większy promień wybuchu.

  • Wspólne zasoby mogą współdzielić tożsamość obciążenia i mieć mniej znaczące dzienniki inspekcji w dziennikach dostępu.

  • Mechanizmy kontroli zabezpieczeń sieci muszą być wystarczająco szerokie, aby obejmowały wszystkie współlokarze zasoby. Ta konfiguracja potencjalnie narusza zasadę najniższych uprawnień dla niektórych zasobów.

  • Wspólne lokalizowanie różnych aplikacji lub danych na hoście udostępnionym może prowadzić do rozszerzenia wymagań dotyczących zgodności i mechanizmów kontroli zabezpieczeń na aplikacje lub dane, które w przeciwnym razie byłyby poza zakresem. Rozszerzenie zakresu wymaga dodatkowej kontroli zabezpieczeń i inspekcji składników współlokujących.

Kompromisy optymalizacji kosztów z doskonałością operacyjną

Kompromis: naruszone pojemności cyklu tworzenia oprogramowania (SDLC). Proces SDLC obciążenia zapewnia rygor, spójność, specyfikę i priorytetyzację w celu zmiany zarządzania obciążeniami.

  • Zmniejszenie nakładu pracy związanej z testowaniem w celu zaoszczędzenia czasu i kosztów związanych z personelem testowym, zasobami i narzędziami może spowodować zwiększenie liczby usterek w środowisku produkcyjnym.

  • Opóźnienie spłaty długu technicznego w celu skupienia wysiłków personelu na nowych funkcjach może prowadzić do spowolnienia cykli rozwoju i ogólnej mniejszej elastyczności.

  • Deprioritizing documentation to focus personnel efforts on development to product development can lead to longer onboarding time for new employees, impact the effectiveness of incident response, and compromise compliance requirements ( Czas opracowywania produktów może prowadzić do dłuższego czasu dołączania nowych pracowników, wpływać na skuteczność reagowania na zdarzenia i naruszać wymagania dotyczące zgodności.

  • Brak inwestycji w szkolenia prowadzi do zatagowanych umiejętności, zmniejszając zdolność zespołu do wdrażania nowszych technologii i praktyk.

  • Usunięcie narzędzi automatyzacji w celu zaoszczędzenia pieniędzy może spowodować, że pracownicy poświęcają więcej czasu na zadania, które nie są już zautomatyzowane. Zwiększa również ryzyko błędów i niespójności.

  • Zmniejszenie wysiłków związanych z planowaniem, takich jak określanie zakresu i priorytetyzacja działań, zmniejszenie wydatków może zwiększyć prawdopodobieństwo przeróbki ze względu na niejasne specyfikacje i słabe wdrożenie.

  • Unikanie lub zmniejszanie działań ciągłego ulepszania, takich jak retrospektywy i raporty po zdarzeniu, aby zespół obciążeń skupił się na dostarczaniu, może stworzyć nieodebrane możliwości optymalizacji rutynowych, nieplanowanych i awaryjnych procesów.

Kompromis: Zmniejszona zauważalność. Możliwość obserwowania jest niezbędna, aby zapewnić, że obciążenie ma istotne alerty i pomyślne reagowanie na zdarzenia.

  • Zmniejszenie ilości dzienników i metryk w celu obniżenia kosztów magazynowania i transferu zmniejsza widoczność systemu i może prowadzić do:

    • Mniejsza liczba punktów danych do tworzenia alertów związanych z niezawodnością, zabezpieczeniami i wydajnością.
    • Luki w zakresie reagowania na zdarzenia.
    • Ograniczona możliwość obserwowania interakcji lub granic związanych z zabezpieczeniami lub zgodnością.
  • Wzorce projektowe optymalizacji kosztów mogą dodawać składniki do obciążenia, zwiększając jego złożoność. Strategia monitorowania obciążenia musi obejmować te nowe składniki. Na przykład niektóre wzorce mogą wprowadzać przepływy obejmujące wiele składników lub przenosić procesy z serwera do klienta. Te zmiany mogą zwiększyć złożoność korelowania i śledzenia informacji.

  • Zmniejszenie inwestycji w narzędzia do obserwacji i konserwacja skutecznych pulpitów nawigacyjnych może zmniejszyć możliwość uczenia się z produkcji, weryfikowania wyborów projektowych i informowania o projekcie produktu. Zmniejszenie to może również utrudnić działania reagowania na zdarzenia i utrudnić osiągnięcie celu czasu odzyskiwania i celu SLO.

Kompromis: Odroczona konserwacja. Zespoły ds. obciążeń powinny zachować kod, narzędzia, pakiety oprogramowania i systemy operacyjne, które są poprawiane i aktualne w odpowiednim czasie i uporządkowanej kolejności.

  • Zezwolenie na kontrakty konserwacyjne z dostawcami narzędzi wygasają może spowodować pominięcie funkcji optymalizacji, rozwiązań usterek i aktualizacji zabezpieczeń.

  • Zwiększenie czasu między poprawkami systemu w celu zaoszczędzenia czasu może prowadzić do nieodebranych poprawek usterek lub braku ochrony przed zmieniającymi się zagrożeniami bezpieczeństwa.

Kompromisy optymalizacji kosztów z wydajnością

Filary Optymalizacja kosztów i Wydajność wydajności ustalają priorytety maksymalizacji wartości obciążenia. Wydajność podkreśla spełnienie celów wydajności bez wydawania więcej niż to konieczne. Optymalizacja kosztów podkreśla maksymalizację wartości generowanej przez zasoby obciążenia bez przekraczania celów wydajności. W związku z tym optymalizacja kosztów często poprawia wydajność. Istnieją jednak kompromisy związane z wydajnością związaną z optymalizacją kosztów. Te kompromisy mogą utrudnić osiągnięcie celów wydajności i utrudnić ciągłą optymalizację wydajności.

Kompromis: Niedostateczna aprowizacja lub nieskalowane zasoby. Efektywne pod względem wydajności obciążenie ma wystarczającą ilość zasobów do obsługi zapotrzebowania, ale nie ma nadmiernego nieużywanego obciążenia, nawet jeśli wzorce użycia zmieniają się.

  • Zmniejszenie kosztów poprzez obniżenie rozmiaru zasobów może pozbawić aplikacji zasobów. Aplikacja może nie być w stanie obsłużyć znacznych wahań wzorców użycia.

  • Ograniczenie lub opóźnienie skalowania w celu ograniczenia lub zmniejszenia kosztów może spowodować niewystarczającą podaż, aby zaspokoić zapotrzebowanie.

  • Ustawienia skalowania automatycznego, które są skalowane w dół agresywnie w celu zmniejszenia kosztów, mogą spowodować, że usługa nie jest przygotowana na nagłe wzrosty zapotrzebowania lub powodować częste wahania skalowania (flapping).

Kompromis: Brak optymalizacji w czasie. Ocena skutków zmian funkcjonalności, zmian wzorców użycia, nowych technologii i różnych podejść do obciążenia jest jednym ze sposobów na zwiększenie wydajności.

  • Ograniczenie skupienia się na opracowywaniu wiedzy fachowej w zakresie optymalizacji wydajności w celu nadania priorytetów dostawom może spowodować chybienie możliwości poprawy wydajności użycia zasobów.

  • Usunięcie narzędzi do testowania wydajnościowego lub monitorowania zwiększa ryzyko niewykrytych problemów z wydajnością. Ogranicza również możliwość wykonywania przez zespół obciążeń w cyklach miary/ulepszania.

  • Zaniedbywane obszary podatne na obniżenie wydajności, takie jak magazyny danych, mogą stopniowo pogarszać wydajność zapytań i podnosić ogólne użycie systemu.

Zapoznaj się z kompromisami dotyczącymi innych filarów: