Wykorzystanie rozszerzeń pakietów CloudLinux w planach taryfowych cPanel

Rozszerzenia pakietów CloudLinux są opłacalne, jeśli pakiety cPanel jednolite profile zasobów LVE dla standardowych planów hostingowych. Uzupełniają one plany o limity dotyczące procesora, pamięci, procesów i operacji wejścia/wyjścia, ale nie zastępują ani analizy błędów, ani planowania wydajności. Narzędzie LVE Manager służy do kontroli i ukierunkowanego zarządzania wyjątkami; integracja z systemem rozliczeniowym zapewnia spójność między produktem, provisioningiem i przypisaniem pakietów. Kluczowe znaczenie ma ustalenie, czy wąskie gardło faktycznie występuje w procesach internetowych, dostępie do baz danych czy w systemie plików.

Prawidłowe klasyfikowanie rozszerzeń pakietów CloudLinux

W kontekście cPanel funkcja CloudLinux Package Extensions oznacza konkretnie Rozszerzenie cPanel LVE To właśnie ma na myśli. Rozszerza ona standardowe pakiety cPanel o pola dotyczące limitów zasobów. Pakiet cPanel opisuje przede wszystkim produkt hostingowy, który można zarezerwować i przypisać, na przykład plan dla początkujących lub biznesowy. Rozszerzenie to uzupełnia ten model taryfowy o techniczne limity, które mają obowiązywać dla kont przypisanych do danego pakietu. CloudLinux dokumentuje tę integrację dla cPanel, a nie jako uniwersalną funkcję pakietową dla wszystkich paneli sterowania lub komponentów CloudLinux.

Termin ten należy odróżnić od ogólnych rozszerzeń pakietów cPanel. Stanowią one framework, dzięki któremu rozszerzenia mogą zapisywać dodatkowe zmienne i pola wprowadzania danych w pakietach i kontach. Rozszerzenie LVE stanowi konkretny przykład zastosowania tego mechanizmu: zapisuje ono wartości LVE w pakiecie, zamiast jedynie zarządzać dowolnie zdefiniowanymi cechami produktu. Wyjaśnia to również, dlaczego zmiany w danych rozszerzeń związanych z pakietami, w połączeniu z kontami i późniejszymi zmianami pakietów, muszą być starannie zaplanowane.

Der LVE Manager nie jest natomiast konkurencyjnym rozszerzeniem pakietu. Stanowi centralne narzędzie do zarządzania w systemie CloudLinux, służące do kontroli limitów, pakietów, kont i raportów. Administratorzy mogą tam sprawdzać parametry pakietów oraz, w razie potrzeby, zarządzać indywidualnymi ustawieniami kont; natomiast rozszerzenie LVE zapewnia, że ustawienia LVE stanowią bezpośrednią część zarządzania pakietami w cPanel. W przypadku standardowych planów hostingu współdzielonego oba rozwiązania wzajemnie się uzupełniają: cPanel odzwierciedla plan taryfowy i proces provisioningu, natomiast LVE Manager zapewnia przejrzystość w zakresie faktycznie zarządzanych reguł dotyczących zasobów.

Osobno należy również traktować rozszerzenia w selektorze PHP. Chodzi tu o moduły PHP i środowiska uruchomieniowe, które można wybierać, a nie o ograniczenia dotyczące procesora, pamięci, procesów czy nośników danych na koncie klienta. Na przykład naprawienie braku rozszerzenia PHP nie powoduje automatycznie zmiany pojemności LVE danego planu taryfowego. Z drugiej strony wyższy limit LVE nie poprawia niekompatybilnej konfiguracji PHP. To rozróżnienie zapobiega błędnemu traktowaniu zakresu funkcjonalności aplikacji i izolacji zasobów jako tego samego ustawienia.

Z tego powodu rozszerzenie to ma praktyczne znaczenie przede wszystkim wtedy, gdy taryfa ma otrzymać powtarzalną gwarancję wydajności w postaci profilu zasobów. Nie zastępuje ona planowania wydajności serwera ani analizy konkretnych przyczyn obciążenia. Tworzy jednak wiążące przyporządkowanie: konto wraz z pakietem cPanel otrzymuje nie tylko limity i cechy produktu, ale także przewidziane limity LVE.

Wymagania techniczne i skuteczne przypisanie

Same pola pakietów nie ograniczają jeszcze procesów. Aby wartości LVE były faktycznie egzekwowane, konieczne jest posiadanie systemu operacyjnego CloudLinux, jądra obsługującego LVE oraz załadowanego modułu jądra LVE. W przypadku braku tej podstawy technicznej wartości mogą wprawdzie pojawiać się w interfejsie, ale nie zapewniają oczekiwanego efektu izolacji dla kont hostingowych. Dlatego przed przystąpieniem do jakichkolwiek zmian taryfowych należy przeprowadzić analizę stanu platformy serwerowej, a nie wybierać rzekomo odpowiednie wartości liczbowe.

Poniższe polecenia służą wyłącznie do odczytu. Należy je wykonać w powłoce z odpowiednimi uprawnieniami, umożliwiającymi sprawdzenie identyfikatora jądra i załadowanych modułów. Nie zmieniają one ani pakietów, ani limitów, ani nie uruchamiają ponownie usług.

uname -r
lsmod|grep lve

Wydanie uname -r wyświetla aktualną wersję jądra. Za pomocą lsmod|grep lve Sprawdzasz, czy załadowany jest odpowiedni moduł LVE. Żadne z tych sprawdzeń nie potwierdza, czy poszczególne taryfy są właściwie dobrane pod względem merytorycznym; wyjaśniają one wyłącznie, czy spełniony jest istotny warunek technicznej realizacji. W celu dalszej klasyfikacji proces sprawdzania powinien zatem obejmować również przypisanie pakietu, stan konta oraz późniejsze analizy błędów.

Nawet jeśli LVE działa poprawnie, limit pakietu nie jest niezależny od przypisania do konta. Wartości pakietów mają zasadniczo zastosowanie do kont przypisanych do danego pakietu. CloudLinux zwraca jednak uwagę na ważny wyjątek: jeśli właściciel pakietu i właściciel konta nie są tą samą osobą, limity pakietów nie są stosowane; zamiast tego obowiązują Limity domyślne w praktyce. Może to mieć znaczenie na przykład w przypadku szczególnych konfiguracji administracyjnych lub modeli współpracy z dystrybutorami. Sama nazwa taryfy nie stanowi zatem wystarczającego dowodu na skuteczne ograniczenie konkretnego konta.

Ponadto konta mogą posiadać indywidualne wartości LVE, które odbiegają od profilu pakietu. Takie wyjątki niekoniecznie oznaczają błąd, ale sprawiają, że weryfikacja przebiega wieloetapowo: najpierw należy potwierdzić techniczną podstawę LVE, następnie prawidłowe przyporządkowanie pakietu i właściciela, a na końcu ewentualny indywidualny profil. Dopiero na podstawie tej kolejności można ustalić, dlaczego konto klienta otrzymuje inne zasoby niż konto taryfowe, które wydaje się być podobne.

Jakie znaczenie mają SPEED, PMEM, EP i I/O w hostingu

Limity LVE zapewniają ochronę hostingu współdzielonego poprzez oddzielenie zasobów poszczególnych kont od siebie. SPEED ogranicza dostępną moc procesora; w przypadku wartości procentowej 100 % odpowiada jednemu rdzeniowi procesora. Jeśli limit ten zostanie niemal wyczerpany, zadania PHP, zadania cron lub strony dynamiczne niekoniecznie zakończą się natychmiastowym błędem, ale będą wymagały więcej czasu. W rezultacie żądania mogą pozostawać aktywne dłużej i pośrednio powodować większe obciążenie innych limitów. Limity procesora należy zatem oceniać łącznie z czasami odpowiedzi, liczbą żądań równoległych oraz rodzajem aplikacji.

W przypadku pamięci PMEM rzeczywista ilość pamięci fizycznej wykorzystywanej przez LVE. W przypadku przekroczenia tego limitu CloudLinux może, po zwolnieniu pamięci buforowej, zakończyć procesy w danym LVE. Dla użytkowników może to skutkować błędami HTTP 500 lub HTTP 503. PMEM stanowi zatem kluczowy limit ochronny, ale nie zastępuje analizy przyczyn: wtyczki wymagające dużej ilości pamięci, zbyt duże procesy robocze PHP lub błędne skrypty pozostają zagrożeniem dla działania systemu nawet przy wyższym limicie.

VMEM określa zapotrzebowanie na pamięć wirtualną. CloudLinux uznaje VMEM za przestarzały i zaleca ustawienie tej wartości na 0 ustawić lub wyłączyć to ograniczenie, ponieważ aktywne limity VMEM mogą powodować nieoczekiwane problemy. Jeśli konto osiągnie nadal ustawiony limit VMEM, dalsze przydziały pamięci mogą zostać zablokowane; licznik fVMEM wzrasta, a procesy lub żądania CGI/PHP mogą zakończyć się niepowodzeniem z kodem HTTP 500 lub HTTP 503. Dlatego PMEM jest decydującym limitem pamięci dla nowych lub zaktualizowanych profili hostingu współdzielonego.

W przypadku istniejących systemów przejście na nowy system powinno jednak odbywać się w sposób kontrolowany. Przed wyłączeniem VMEM należy zarejestrować istniejące wartości pakietów i kont, generację systemu operacyjnego oraz zależności starszych konfiguracji. Następnie zmianę można najpierw obserwować na odpowiednim koncie testowym. Ta ostrożność nie zmienia jednak podstawowego zalecenia: VMEM nie powinno być uwzględniane w nowych modelach taryfowych jako równoważny drugi limit pamięci obok PMEM.

EP oznacza procesy internetowe zachodzące jednocześnie i w ten sposób odzwierciedla równoległe aktywne żądania internetowe. Wyczerpany Limit EP może spowodować, że serwer WWW zwróci kod błędu HTTP 508. EP nie jest zatem bezpośrednim limitem odwiedzających: kilka wolnych, dynamicznych żądań może wyczerpać limit w takim samym stopniu, jak wiele krótkich wywołań. Natomiast NPROC ogranicza całkowitą liczbę procesów na koncie. Duża liczba uruchomionych procesów może wynikać na przykład z równoległego wykonywania skryptów PHP, zadań w tle lub nieodpowiednio zaplanowanych zadań cron.

Wskaźnik IO określa przepustowość nośnika danych w KB/s, a IOPS – liczbę operacji odczytu i zapisu na sekundę. W przypadku zbyt małej liczby operacji wejścia/wyjścia procesy zazwyczaj zwalniają, zamiast zostać natychmiast zakończone. Po osiągnięciu limitu IOPS operacje odczytu i zapisu czekają do następnego interwału sekundowego. Jest to zauważalne na przykład w przypadku wielu drobnych operacji dostępu do plików, plików pamięci podręcznej lub aplikacji intensywnie przetwarzających dane. Widoczne wąskie gardło nie musi zatem automatycznie oznaczać problemu z procesorem: dopiero rodzaj danego ograniczenia wskazuje, czy to czas obliczeniowy, pamięć, równoległość, przepustowość czy częstotliwość operacji spowalnia działanie aplikacji.

Tworzenie pakietów hostingowych jako spójnych profili zasobów

W przypadku standardowych planów hostingu współdzielonego pakiety cPanel z zaprogramowanymi wartościami LVE stanowią przede wszystkim narzędzie do spójnego przydzielania zasobów. Plan podstawowy, standardowy i o wyższej wydajności mogą otrzymać odpowiednio jasno zdefiniowany profil zasobów. Gdy nowe konto klienta zostanie przypisane do odpowiedniego pakietu, jego limity obowiązują bez konieczności dodatkowej ręcznej obsługi każdego konta. Zapobiega to sytuacji, w której taryfy o tej samej nazwie z czasem otrzymują różne limity procesora, pamięci lub operacji wejścia/wyjścia.

Profil pakietu opisuje nie tylko techniczny limit, ale także przewidywalną relację między planem taryfowym, oczekiwanym wykorzystaniem a dostępną wydajnością serwera. Plan podstawowy może obejmować proste strony internetowe, które dobrze nadają się do buforowania, podczas gdy wyższy plan taryfowy zapewnia większą swobodę działania dla aplikacji dynamicznych lub okresowych szczytów obciążenia. Rozszerzenie pakietu ma sens, gdy cPanel jest głównym źródłem przypisywania planów taryfowych, a limity mają być przenoszone wraz ze zmianą pakietu. Zmianami można zarządzać zarówno w pakietach cPanel, jak i w menedżerze LVE.

Nie ma jednak uniwersalnych, prawidłowych wartości liczbowych dla takich profili. Decydujące znaczenie mają między innymi konfiguracja procesora i pamięci masowej, serwer WWW i moduł obsługi PHP, stosowane pamięci podręczne, typowe aplikacje, jednoczesne szczyty obciążenia, a także własna strategia nadmiarowości. Limit mocy obliczeniowej procesora, który jest uzasadniony na serwerze obsługującym głównie statyczne strony internetowe, może okazać się zbyt niski dla zasobów zawierających wiele niebuforowanych żądań CMS. Podobnie szybsza pamięć masowa może pozwalać na inny stosunek operacji wejścia/wyjścia (IO) do operacji na sekundę (IOPS) niż wolniejszy system pamięci masowej.

Warto postępować stopniowo: najpierw zdefiniuj kilka jasno zróżnicowanych pakietów zamiast wielu trudnych do rozróżnienia wariantów. Następnie obserwuj wykorzystanie i awarie w podziale na taryfy i sprawdź, czy powtarzające się ograniczenia faktycznie pasują do profilu produktu, czy też wynikają z pojedynczych, wadliwych aplikacji. Dopiero potem należy celowo dostosować limity. W ten sposób pozostają Pakiety hostingowe To zrozumiałe, a decyzje dotyczące przepustowości opierają się na rzeczywistym rozkładzie obciążenia, a nie na ogólnych danych dotyczących liczby odwiedzających.

Porównanie parametrów LVE i ścieżek administracyjnych

Poniższe wartości ograniczają różne wąskie gardła. Dla celów ustalania taryf ich widoczny wpływ jest ważniejszy niż sama techniczna definicja: na przykład wysoka wartość przestrzeni dyskowej nie rekompensuje ani zbyt małej mocy procesora, ani wyczerpanych procesów wejściowych. I-węzły również nie należą do zasobów LVE, lecz do limitów systemu plików. Zgodnie z zaleceniem CloudLinux, VMEM nie powinno być wykorzystywane jako standardowy limit taryfowy, lecz powinno być ustawione na 0 należy ustawić.

Również procedura administracyjna zależy od zadania. Pakiety wartości tworzą standard, podczas gdy narzędzia diagnostyczne nie zmieniają żadnej konfiguracji. Takie przyporządkowanie pomaga uniknąć pochopnego przenoszenia szczególnych przypadków operacyjnych do nowych taryf.

Oddzielne traktowanie wierzchołków CMS, kont indywidualnych i bazy danych MySQL

W przypadku WordPressa i innych dynamicznych systemów CMS szczyty obciążenia rzadko wynikają wyłącznie z liczby odwiedzających. Powolne żądanie PHP pozostaje aktywne dłużej, co może powodować zator kolejnych żądań przetwarzanych równolegle. Zwiększa to obciążenie EP, mimo że liczba odwiedzin może pozostać niezmieniona. Niewydajne wtyczki, brak buforowania stron lub obiektów, przetwarzanie obrazów, zaplanowane zadania oraz zewnętrzne wywołania API również wpływają na czas działania i zapotrzebowanie na pamięć. Dlatego błąd EP należy najpierw zbadać jako wskazówkę dotyczącą jednocześnie zablokowanych lub długotrwałych żądań internetowych, a nie jako automatyczny dowód na „zbyt dużą liczbę odwiedzających“.

W przypadku migracji, kampanii o ograniczonym czasie trwania lub specjalnej taryfy uzgodnionej w umowie odpowiednim rozwiązaniem może być indywidualny profil LVE dla pojedynczego konta. Wyjątek ten wymaga jednak udokumentowanego powodu, terminu weryfikacji oraz jednoznacznego przypisania odpowiedzialności. W przypadku nagromadzenia się wartości indywidualnych model pakietowy traci swoją porównywalność; wsparcie techniczne i planowanie wydajności stają się bardziej pracochłonne. Ponadto wartości kont należące do rozszerzenia pakietu mogą zostać nadpisane w przypadku późniejszej zmiany pakietu. Indywidualne dostosowania nie powinny zatem być mylnie interpretowane jako trwale niezależne definicje taryfowe.

Ograniczenia procesów internetowych nie rozwiązują automatycznie problemów z bazą danych. Jeśli przyczyną wąskiego gardła są powolne lub liczne zapytania MySQL, należy osobno przeanalizować zapytania, indeksy, blokady oraz operacje wejścia/wyjścia bazy danych. Artykuł ten uzupełnia analizę przyczyn obciążenia MySQL Wykorzystanie schematu wydajności MySQL do monitorowania spojrzenie na poziom aplikacji. MySQL Governor może dodatkowo zarządzać MySQL SPEED i MySQL IO w odniesieniu do poszczególnych pakietów; w tym celu CloudLinux wymaga co najmniej governor-mysql 1.2-80, lvemanager 7.8.3-1, lve-utils 6.4.6-1 oraz alt-python27-cllib 3.2.40-1. Przed wdrożeniem należy sprawdzić te zainstalowane wersje pakietów, zamiast przyjmować założenia dotyczące wersji z innego środowiska.

Należy monitorować limity przed zmianą taryf

Zmiana taryfy powinna rozpocząć się od analizy aktualnej sytuacji. Należy ustalić, do jakiego pakietu cPanel przypisane są dane konta, czy występują indywidualne odstępstwa oraz jakie limity faktycznie obowiązują. Następnie należy przeanalizować błędy LVE pod kątem rodzaju, częstotliwości i czasu wystąpienia. Decydujące znaczenie ma to, czy limit został osiągnięty tylko podczas krótkotrwałego szczytu, czy też jest przekraczany wielokrotnie.

Poniższe polecenia powłoki służą wyłącznie do wyświetlania danych i nie zmieniają ani wartości pakietów, ani limitów. lvectl package-list wyświetla parametry LVE pakietów. lvetop zapewnia aktualny podgląd zasobów. lveps -p przedstawia procesy zachodzące w ramach LVE. Migawki sytuacyjne są pomocne w przypadku nagłych zdarzeń, jednak same w sobie nie wystarczają do podjęcia decyzji taryfowej.

lvectl package-list
lvetop
lveps -p

Przypisz każde zdarzenie do odpowiedniego poziomu przyczyny. Błędy typu EP lub SPEED mogą wskazywać na powolne dynamiczne żądania internetowe, natomiast błędy typu IO i IOPS raczej na dostęp do plików lub baz danych. Weź pod uwagę godzinę, czas trwania, konta, których dotyczy problem, a także równoległe zadania cron lub prace konserwacyjne. Szczegółowy przewodnik dotyczący interpretacji błędów i wzorców czasowych można znaleźć w Jak prawidłowo analizować raporty dotyczące wykorzystania zasobów w CloudLinux. Najpierw zmień profil na odpowiednim koncie testowym i przenieś go na plan taryfowy dopiero wtedy, gdy dane potwierdzą zasadność tej zmiany.

Jak unikać typowych błędów związanych z rozszerzeniami pakietów

Częstym błędem jest to, że, VE_DEFAULT jak pakiet taryfowy, który można zarezerwować. Ta nazwa w LVE Managerze odnosi się do widoku domyślnych limitów, ale nie jest to rzeczywisty pakiet LVE. Osobno istnieje pakiet cPanel o nazwie default ma szczególne znaczenie dla kont, do których przypisano ten pakiet. Oba pojęcia nie są zatem zamienne ani nie stanowią podstawy do zmiany struktur taryfowych bez przeprowadzenia analizy.

Również wartości domyślne nie są dziedziczone dynamicznie przez już skonfigurowane pakiety. Jeśli limit domyślny zostanie później zmieniony, CloudLinux nie zaktualizuje automatycznie wcześniej ustalonych, odmiennych wartości istniejącego pakietu niedomyślnego. Podobnie w przypadku LVE_DEFAULT Przejęta wartość nie jest automatycznie stosowana do bieżącego pakietu LVE. Dlatego po dokonaniu globalnej korekty należy sprawdzić konkretne wartości pakietów, zamiast wyciągać wnioski na temat aktualnej konfiguracji taryfowej na podstawie widoku domyślnego.

Indywidualne limity dla konta mają sens, jeśli mają jasny cel i są ograniczone czasowo, na przykład podczas migracji. Sprawiają one jednak, że model pakietowy staje się mniej przejrzysty. W przypadku rozszerzeń pakietów cPanel późniejsze zmiany w przypisanym pakiecie mogą nadpisać wartości konta. Dlatego należy oddzielnie rejestrować wszelkie odstępstwa i sprawdzać je przed każdą aktualizacją pakietu; nie stanowią one niezawodnego, długoterminowego rozwiązania dla taryfy, która w rzeczywistości jest odrębna.

Nie należy utożsamiać z limitami LVE Limity i-nodów. Ograniczają one liczbę plików i katalogów za pomocą limitów systemowych, a nie obciążenia procesora, pamięci, liczby procesów ani przepustowości nośnika danych danego LVE. Narzędzie cl-quota działa w oparciu o miękkie i twarde limity i-nodów, a nie o bloki pamięci. Odmienne, starsze wartości w plikach użytkowników cPanel nie stanowią zatem dowodu przeciwko egzekwowaniu tych limitów: decydujące znaczenie mają limit systemowy oraz wynik generowany przez CloudLinux.

W końcu rozszerzenia PHP Selector i rozszerzenie cPanel LVE należą do różnych obszarów zarządzania. Te pierwsze kontrolują dostępne rozszerzenia PHP, natomiast to drugie uzupełnia pakiety cPanel o limity zasobów. Kto pomiesza te dwie funkcje, ten łatwo szuka przyczyny problemu z wydajnością lub provisioningiem w niewłaściwym miejscu.

Wybierz rozszerzenie pakietu, menedżera LVE lub integrację z systemem rozliczeniowym

Die Rozszerzenie cPanel LVE Rozwiązanie to sprawdza się, gdy pakiety cPanel stanowią główny model planów hostingowych. Ich zaletą jest spójne przydzielanie zasobów: gdy nowemu kontu przypisywany jest plan, jego pola LVE stają się częścią profilu pakietu. Rozwiązanie to sprawdza się szczególnie w przypadku jasno zdefiniowanych produktów hostingu współdzielonego o powtarzalnych poziomach wydajności. CloudLinux wymienia również integrację z istniejącymi systemami rozliczeniowymi jako obszar zastosowania tej integracji.

Der LVE Manager Nie zastępuje on tego modelu taryfowego, lecz uzupełnia go jako główny interfejs operacyjny. Jest przydatny do sprawdzania i edytowania wartości pakietów, rozpoznawania indywidualnych wyjątków lub monitorowania skutków działania limitów. W przypadku pojedynczego, ograniczonego czasowo wyjątku, świadomie udokumentowana rozbieżność na koncie jest często bardziej odpowiednia niż nowy pakiet standardowy. Gdy takie wyjątki zaczynają się mnożyć, przemawia to za utworzeniem dodatkowego profilu taryfowego lub zmianą struktury produktów.

A Integracja systemów rozliczeniowych Warto to zrobić, jeśli proces składania zamówienia, produkt i pakiet cPanel mają mieć na stałe tę samą przypisanie. Nie automatyzuje to jednak merytorycznej decyzji dotyczącej odpowiednich wartości granicznych: podstawą pozostają konfiguracja sprzętowa, profil obciążenia oraz zaobserwowane awarie. W przypadku wielu serwerów WHM API może dodatkowo zarządzać rozszerzeniami pakietów. Wymaga to szczególnej staranności: podczas ustawiania _PACKAGE_EXTENSIONS Wywołanie musi zawierać pełną listę żądanych rozszerzeń. Rozszerzenia, które nie zostały wymienione, zostaną usunięte; niekompletne wywołanie automatyzacji może zatem nieumyślnie usunąć istniejące funkcje pakietu.

W celu automatyzacji zaleca się zatem procedurę obejmującą odczyt stanu rzeczywistego, pełną listę docelową, weryfikację na pakiecie nieprodukcyjnym oraz przejrzystą historię zmian. Jeśli nazwy pakietów zostaną zmienione w ramach własnej lub zewnętrznej integracji z panelem sterowania, należy również zaktualizować integrację z CloudLinux; CloudLinux udokumentował w tym celu wywołanie haka. Jest to konkretny przypadek integracji, a nie ogólne standardowe działanie dla każdej zmiany nazwy w cPanel.

W praktyce wybór wygląda zatem następująco: Package Extension do standardowego przypisywania taryf, LVE Manager do kontroli i uzasadnionych wyjątków, Billing do spójnego udostępniania produktów. W przypadku wąskich gardeł w bazie danych lub niejednolitych indywidualnych wymagań żadne z tych narzędzi nie wystarczy jako sam schemat; najpierw należy wyjaśnić rzeczywistą przyczynę wąskiego gardła.