Od samego początku idea skalowania jest niemal zawsze powiązana z wynikami biznesowymi. „Kiedy mówimy o skalowaniu, zwykle mamy na myśli naszą zdolność do obsługi większej liczby klientów, dostarczania funkcji kluczowych dla przychodów lub ekspansji na nowe rynki geograficzne” — mówi Andrey Korchak, były dyrektor techniczny i współzałożyciel Monite.
Jednak ten cel biznesowy rzadko przekłada się bezpośrednio na warstwę backendową. Zamiast tego dla członka kadry kierowniczej najwyższego szczebla skalowanie IT i inżynierii oznacza montowanie większej liczby serwerów, konfigurowanie większej liczby przepływów pracy, wdrażanie kolejnych inżynierów i łączenie kolejnych narzędzi, by po prostu utrzymać się na powierzchni.
Na papierze idea ta wygląda jak stale działający silnik wzrostu. W praktyce często prowadzi jednak do obciążenia operacyjnego, kosztów ogólnych, długu technologicznego i zmęczenia zespołu. Wkrótce wysiłki związane ze skalowaniem zaczynają zwiększać złożoność szybciej, niż dostarczają wartość.
Pobierz bezpłatny „Podręcznik skalowania IT” i otrzymaj listy kontrolne, kartę wyników oraz 30-dniowy plan wdrożenia w jednym pakiecie, który można łatwo udostępniać. To ten sam zestaw narzędzi, którego zespoły opisane w tym artykule użyły, aby ograniczyć liczbę zbędnych narzędzi, odblokować możliwości zespołów deweloperskich i zaoszczędzić tysiące na wydatkach na chmurę.
Kiedy zasada „po prostu dodaj więcej” niszczy nowoczesne IT
Kiedy zespoły odczuwają presję skalowania, domyślna reakcja niemal zawsze jest taka sama: po prostu dodaj więcej. Więcej pulpitów nawigacyjnych. Więcej automatyzacji. Więcej pracowników. Jednak w przypadku zespołów IT, które już działają na pełnych obrotach, prowadzi to do powolnego załamania pod ciężarem złożoności, fragmentacji i wypalenia. Oto dlaczego wciąż do tego dochodzi:
Have an account? Log In
Urok syndromu lśniącego obiektu
Obsesja na punkcie nowych narzędzi jest formą operacyjnego eskapizmu i często wywołuje syndrom lśniącego obiektu. „To przekonanie, że najnowsza technologia będzie panaceum, które wybawi ich od złożoności, zamiast rozwiązać konkretną potrzebę biznesową” — ostrzega Scott Willson, dyrektor marketingu produktowego w xtype. „Jednak częściej niż nie rozwiązania te tworzą więcej tarć, niż ich eliminują.”
Zespoły sięgają po najnowszego asystenta AI, pulpit nawigacyjny lub wtyczkę automatyzującą, sądząc, że odciążą one pracowników. Jednak każde nowe narzędzie wnosi własne interfejsy API, konfiguracje i własną wersję „prawdy”.
Z czasem wywołuje to efekt domina, w którym koordynacja między zespołami zaczyna się załamywać, a deweloperzy poświęcają więcej czasu na zarządzanie interfejsami i integrowanie systemów niż na dostarczanie kodu.
Ironią jest to, że próba rozwiązania problemu nadmiaru poprzez dodawanie jeszcze większej liczby elementów staje się właśnie problemem, w którym zespoły obecnie toną.
Rozrost narzędzi wskutek przeciążenia AI
Rozwój narzędzi AI przyspieszył tempo, w jakim zespoły mogą się skalować. Można zintegrować asystenta programistycznego z IDE, zbudować chatbota za pomocą jednego wdrożenia lub utworzyć nowe narzędzie do obserwowalności, aby natychmiast uzyskać wgląd w dane (to jedna z wielu korzyści płynących z narzędzi do obserwowalności danych).
Jednak, jak ostrzega Sumit Johar, dyrektor ds. informacji w BlackLine, skalowanie bez struktury prowadzi do „fragmentarycznych ekosystemów, które podważają interoperacyjność, zarządzanie i skalowalność”.
Słowa Sumita znajdują również odzwierciedlenie w obecnym rozroście AI: przeciętne przedsiębiorstwo wdraża obecnie ponad 9,6 aplikacji AI, a najwięksi użytkownicy korzystają nawet z 80 aplikacji AI. Takie niekontrolowane skalowanie bez jasnej propozycji wartości drenuje budżety, rozbija przepływy pracy, a nawet dubluje wysiłki inżynieryjne i informatyczne.
A ponieważ AI jest złożona, większość interesariuszy nie dostrzega nawet narastającego rozrostu. „Wprowadza dodatkowe komplikacje, takie jak obawy dotyczące prywatności danych, wyzwania związane z integracją oraz dylemat: budować czy kupić”. To, co miało być skalowaniem, ostatecznie osłabia te same systemy, które miało wzmacniać.
Rozrost procesów paraliżujący zespoły inżynieryjne
Zdaniem Scotta dług procesowy jest zarówno przyczyną, jak i skutkiem nieprzemyślanych działań związanych ze skalowaniem. „Wiele zespołów technologicznych i biznesowych już działa na granicy swoich możliwości lub ją przekracza” — wyjaśnia. Kiedy więc nagle pojawia się duża inicjatywa, nie trafia na pusty grunt, lecz do już obciążonego systemu.
Bez czasu na przemyślane budowanie przepływów pracy zespoły wracają do „ręcznych przepływów pracy, nieefektywnych przekazań oraz doraźnych procesów i zasad, które z czasem się nawarstwiają”.
Te rozwiązania tymczasowe kumulują się w dług procesowy, utrudniając każde zadanie i spowalniając każde dostarczenie. Choć rzadko pojawia się on na pulpicie nawigacyjnym, po cichu osłabia skalowalność, do której dąży organizacja.
More Articles
Stwórz podręcznik „mniej znaczy więcej”
Nowoczesne IT nie załamuje się z powodu braku narzędzi lub procesów. Załamuje się z powodu ich nadmiaru. Oto nasz bezpłatny „Podręcznik skalowania IT”, który pomoże Ci osiągnąć „prawdziwą skalę”, a nie ślepe gromadzenie.
- Przeprowadź audyt swojego stosu IT
Slav Kulik, dyrektor generalny Plan A Technologies, uważa audyt za naturalny pierwszy krok pozwalający zidentyfikować potencjalne problemy ze „skalowalnością”, zanim przerodzą się w pełnowymiarowy kryzys. „Zbyt często widzimy organizacje, które tak bardzo koncentrują się na przyszłości, że nie potrafią również spojrzeć wstecz”. Dokładny audyt przeprowadzany co 3–5 lat pomaga rozwiązać ten problem, ujawniając, co działa, a co jedynie obciąża system.
Zaangażuj osoby z obszarów inżynierii, bezpieczeństwa, DevOps i biznesu, aby udokumentować każde obecnie używane narzędzie, każdy przepływ pracy i każdy proces. Sumit stosuje podobny proces w swoim przedsiębiorstwie, gdzie rada ds. technologii, przy wsparciu dyrektora finansowego, podejmuje wszystkie decyzje związane z technologią.
„Wymagamy, aby nowe inwestycje w oprogramowanie były przedstawiane wraz z dogłębnym zrozumieniem technologii, jej ROI oraz jej wpływu na wydajność IT. Ten rygorystyczny proces pomaga powstrzymać wdrażanie technologii typu „miło mieć”.
Gdy lista będzie gotowa, podziel swój stos technologiczny na kategorie: obserwowalność, wdrażanie i reagowanie na incydenty. Przypisz każdemu narzędziu ocenę zakłóceń w skali od 0 do 5, w zależności od tego, w jakim stopniu wpływa ono na produktywność programistów, zaśmieca istniejące przepływy pracy lub powoduje problemy w kolejnych etapach po usunięciu.
Najprawdopodobniej odkryjesz stos pełen narzędzi wdrożonych w dobrej wierze, które nie spełniają już swojego przeznaczenia. To sygnał, aby rozważyć konsolidację: zastąp narzędzia jednofunkcyjne platformami obsługującymi wiele zastosowań albo zbuduj komponowalne usługi wewnętrzne, które będą mogły rozwijać się wraz ze stosem.
- Stwórz silnik skalowalności projektowanej od początku
Andrey zaleca utworzenie serii punktów kontrolnych w procesie projektowania, które pomogą zachować skalowalność pomimo złożoności systemu. Jego model dzieli ten proces na cztery rygorystycznie techniczne etapy:
- Etap 1 – Udowodnienie, że technologię można zbudować: Na tym etapie sprawdzasz, czy podstawowa technologia jest w ogóle wykonalna. Zespół jest niewielki, ale wyróżnia się dużym zagęszczeniem kompetencji: inżynierowie analizują architektury, testują biblioteki lub szybko tworzą prototypy, aby rozwiązać kluczowe problemy produktu.
- Etap 2 – Weryfikacja potencjału monetyzacji: Na tym etapie zespół musi przeprowadzić wiele eksperymentów dotyczących monetyzacji, a nawet stworzyć „fikcyjne drzwi”, aby znaleźć funkcje i przypadki użycia, które mogą napędzać solidny i niezawodny proces generowania przychodów. Przykładowo firma SaaS przetestowała wiele wersji swoich planów cenowych i odkryła, że klienci korporacyjni bardziej skłaniali się ku funkcjom zapewniającym możliwość audytowania niż ku automatyzacji. To odkrycie może teraz skłonić do ustalenia na nowo priorytetów w planie rozwoju poziomu premium.
- Etap 3 – Inżynieria dystrybucji: Architektura techniczna musi być teraz zgodna ze zmianami strategii wejścia na rynek. Obejmuje to zrozumienie i dostosowanie się do różnic między poszczególnymi rynkami: w zakresie zgodności, prawa, marketingu, sprzedaży i aspektów technicznych. Weź pod uwagę przepisy dotyczące zgodności w Niemczech i Singapurze albo zmianę modelu sprzedaży z PLG na odgórny.
- Etap 4 – Wzmacnianie trwałości i przyszłych prac badawczo-rozwojowych: Gdy skala jest stabilna, należy skoncentrować się na wdrożeniu redundancji dla wszystkich kluczowych komponentów biznesowych, ustanowieniu solidnych zasad cyberbezpieczeństwa oraz utrzymywaniu praktyk zarządzania wiedzą. Ta podstawa pozwala rozpocząć kolejny cykl innowacji bez ryzyka załamania, a także dbać o krytyczne systemy biznesowe i techniczne.
- Standaryzuj przepływy pracy i zarządzanie
Niespójność w sposobie wdrażania i używania narzędzi IT jest często największą przeszkodą w osiągnięciu rzeczywistej skalowalności. Gdy każdy zespół ma własne skrypty wdrożeniowe, konwencje nazewnictwa lub zasady dostępu, nawet rutynowa koordynacja może stać się źródłem tarć.
Dlatego pierwszym priorytetem powinno być stworzenie ustandaryzowanych przepływów pracy dla zadań, które zespoły wykonują każdego dnia, takich jak wdrażanie usług, reagowanie na incydenty czy udostępnianie infrastruktury.
Te przepływy pracy powinny być objęte kontrolą wersji, łatwe do wykonania i gotowe do uruchomienia przy minimalnej konfiguracji. Jeszcze lepiej, jeśli będą operacyjne od razu po wyjęciu z pudełka, jak narzędzie CLI, które uruchamia nowe usługi przy użyciu wstępnie zatwierdzonych szablonów.
Gdy fundament będzie solidny, wprowadź automatyzację, aby wyeliminować powtarzalne zadania, które obciążają inżynierów.
Jak ujął to Scott, automatyzacja oparta na zasadach, zautomatyzowane zarządzanie oraz zsynchronizowane środowiska odzwierciedlające środowisko produkcyjne to najszybsza droga do zwiększenia zdolności dostarczania zespołów. „Co najważniejsze, tworzą przestrzeń — przestrzeń na koncentrację, innowacje i zrównoważony rozwój zamiast pracy po godzinach napędzanej wypaleniem”.
W praktyce automatyzacja oparta na zasadach przekłada się na ustandaryzowane potoki CI/CD, które automatycznie wdrażają kod, gdy deweloperzy scalą zatwierdzone żądania scalenia. Załóżmy, że dojdzie do incydentu — możesz wtedy użyć zautomatyzowanych szablonów analizy po incydencie, aby natychmiast zebrać kluczowe dane i usprawnić proces reagowania.
Bezpieczeństwo i zgodność również powinny być integralną częścią tych procesów — można to osiągnąć, osadzając zasady jako kod w potokach wdrożeniowych. Jeśli deweloper przypadkowo prześle kod Terraform ze zbyt szerokimi uprawnieniami IAM, narzędzie takie jak Open Policy Agent (OPA) może natychmiast oznaczyć wdrożenie i je zablokować. Pozwala to zaoszczędzić wiele godzin na rozwiązywaniu problemów i domyślnie zapewnia bezpieczeństwo infrastruktury.
Skalowanie szczuplejszej i wydajniejszej infrastruktury IT
W obliczu nieprzewidywalnych wymagań rynku, zamrożonych budżetów i nagłego pojawienia się sztucznej inteligencji opartej na agentach liderzy IT są pod presją, aby robić więcej i robić to szybko.
Jednak dodawanie narzędzi na bieżąco lub improwizowanie zmian procesów rzadko prowadzi do rzeczywistej skalowalności. Zamiast tego skutkuje większą ilością poprawek, wypaleniem zawodowym oraz brakiem spójności między celami biznesowymi a działaniami IT.
Moshin Hussain, dyrektor ds. technologii i wiceprezes wykonawczy ds. inżynierii w firmie LiveRamp, zaleca traktowanie tego podejścia jako „zdywersyfikowanego portfela inwestycyjnego” poprzez odpowiednią alokację zasobów w celu osiągnięcia pożądanego rezultatu.
Przeznacz określone zespoły lub czas na uporządkowane eksperymenty. „Wykorzystuj małe grupy laboratoryjne do testowania nowych technologii, rozwijaj kulturę dzielenia się wiedzą i stosuj metody zwinne, aby szybko iterować” — wyjaśnia Mohsin.
Rzeczywiste skalowanie rozpocznie się, gdy określisz, jak wygląda „dobrze” w przypadku Twojego zespołu. Szybkie reagowanie na incydenty? Mniej nieudanych wdrożeń? Lepsze zgranie produktu i infrastruktury? Gdy już jasno określisz tę wizję, możesz odtworzyć wstecznie systemy, procesy i zasady zarządzania, które ją wspierają.
Proaktywne podejście pozwoli zespołom zachować elastyczność, zdolność adaptacji i dobre przygotowanie do wykorzystywania pojawiających się możliwości. Aby poznać bardziej przemyślane strategie, pobierz nasz bezpłatny „Podręcznik skalowania IT” i zasubskrybuj biuletyn The CTO Club.
