Obsługa dryfu i migracja stanu w skali enterprise
Dwóch inżynierów. Jedna subskrypcja Azure. Obaj uruchomili terraform apply w odstępie kilku minut z osobnych laptopów, każdy z lokalnym plikiem stanu. Efekt: zduplikowane grupy zasobów, konkurujące reguły NSG i stan Terraform, który nie odzwierciedla już rzeczywistości. Nikt nie wie, co jest źródłem prawdy.
To nie jest wymyślony scenariusz. Tak się dzieje, gdy zarządzanie stanem traktowane jest jako sprawa drugorzędna, a nie decyzja projektowa. W środowiskach enterprise Azure — wiele subskrypcji, dziesiątki zespołów, setki modułów — zarządzanie stanem jest tym aspektem praktyki Terraform, który ma największe konsekwencje operacyjne. Jeśli zrobisz to źle, będziesz debugować duchy zasobów, nieudane plany i uszkodzone pliki stanu pod presją produkcyjną.
Ten artykuł omawia, jak od pierwszego dnia prawidłowo zorganizować stan w Azure, jak systematycznie wykrywać i reagować na dryf, oraz nowoczesny zestaw narzędzi do migracji i refaktoryzacji stanu w skali enterprise.
Backend azurerm przechowuje stan Terraform w Azure Blob Storage. Azure automatycznie uzyskuje dzierżawę bloba przed każdą operacją zapisu — to natywna blokada stanu Terraform na Azure. Nie ma odpowiednika DynamoDB do konfiguracji; blokowanie jest wbudowane i nie można go wyłączyć.
Minimalna konfiguracja backendu wygląda prosto, ale konfiguracje produkcyjne wymagają kilku ustawień, których nie ma w domyślnych przykładach dokumentacji.
| terraform { backend „azurerm” { resource_group_name = „rg-terraform-state” storage_account_name = „tfstateenterprise” container_name = „tfstate” key = „teams/platform/network/terraform.tfstate” use_azuread_auth = true # token OAuth2, nie klucz współdzielony use_msi = true # użyj Managed Identity w CI/CD } } |
Ustawienie use_azuread_auth = true to kluczowa zmiana względem domyślnej konfiguracji. Bez niej Terraform uwierzytelnia się przy użyciu klucza dostępu konta storage, który nigdy nie wygasa, nie można go ograniczyć do konkretnego kontenera i pojawia się w logach potoku jako plain text. Z uwierzytelnianiem opartym na Entra można precyzyjnie określić zakres dostępu: przypisz Storage Blob Data Contributor do service principal na poziomie kontenera, nie konta storage.
Trzy ustawienia blob storage, które powinny być w każdym produkcyjnym backendzie stanu: wersjonowanie blobów (każda zmiana stanu tworzy odtwarzalną migawkę), miękkie usuwanie z 14-dniowym oknem retencji (ochrona przed przypadkowym usunięciem) i blob change feed (dziennik audytu każdego odczytu i zapisu do pliku stanu). Żadne z nich nie jest domyślnie włączone.
| WSKAZÓWKA: Izoluj przechowywanie stanu w dedykowanej subskrypcji. Umieść Azure Storage Account dla stanu Terraform w oddzielnej subskrypcji shared services lub platform — nie w tej subskrypcji, którą zarządza. Jeśli atakujący skompromituje service principal zespołu aplikacyjnego, nie powinien również uzyskać dostępu do pliku stanu całej strefy lądowania. Gdy runner CI się zawiesi w trakcie apply, dzierżawa blob pozostaje jako osierocona blokada. Dodaj to do wrappera potoku: az storage blob lease break \ –account-name tfstateenterprise \ –container-name tfstate \ –blob-name teams/platform/network/terraform.tfstate Uruchamiaj to tylko gdy potwierdzisz, że żadne aktywne apply nie jest w toku. Nigdy nie automatyzuj bezwarunkowo. |
Dryf jest używany jako ogólny termin, ale traktowanie wszystkich dryfów tak samo prowadzi do błędnych odpowiedzi. W praktyce występują trzy odrębne typy.
Dryf konfiguracji ma miejsce, gdy ktoś zmienił zasób bezpośrednio w portalu Azure, przez Azure CLI lub inne narzędzie automatyzacji. Zasób istnieje i jest w stanie, ale jego właściwe właściwości nie odpowiadają już temu, czego oczekuje Terraform. SKU maszyny wirtualnej zmienione przez inżyniera ops. Reguła zapory dodana przez portal w trakcie incydentu. Tagi zmodyfikowane przez Azure Policy. Terraform wykryje to przy następnym planie i zaproponuje cofnięcie zmiany.
Dryf stanu ma miejsce, gdy plik stanu nie odzwierciedla już dokładnie tego, co Terraform wdrożył. Ktoś usunął grupę zasobów przez portal bez poinformowania Terraform. Zasób został usunięty przez Azure CLI. Wydarzenie M&A przesunęło subskrypcje i zasoby zmieniły ID. Plik stanu nadal zawiera wpisy dla zasobów, które już nie istnieją, co powoduje błędy resource-not-found w planach.
Dryf pokrycia ma miejsce, gdy zasoby istnieją w Azure bez wiedzy Terraform — brak wpisu w stanie, brak konfiguracji. Zasoby tworzone ręcznie, przez inny zespół lub wdrażane przez szablony ARM/Bicep przed adopcją IaC. Dryf pokrycia nie powoduje błędów planów, co czyni go najbardziej niebezpiecznym: jest niewidoczny, dopóki nie przeprowadzisz audytu środowiska i nie zorientujesz się, że Twój obszar wpływu awarii jest większy niż myślałeś.
| UWAGA: Plik stanu zawiera wrażliwe informacje. ID zasobów, ciągi połączeń, poświadczenia service principal i w niektórych przypadkach hasła do zasobów tworzonych z auto-generowanymi poświadczeniami są przechowywane w plain text w pliku stanu. To znana właściwość stanu Terraform, nie błąd konfiguracji. Oznacza to, że każda osoba z dostępem odczytu do konta storage ma dostęp do tych danych. Traktuj plik stanu z taką samą ostrożnością jak porcelanę. |
Najważniejsza różnica w wykrywaniu dryfu to ta między terraform plan a terraform plan -refresh-only. Zrozumienie jej zapobiega częstemu i kosztownemu błędowi.
terraform plan robi dwie rzeczy: odświeża stan (odczytuje bieżące właściwości zasobów z Azure) i oblicza, jakie zmiany są potrzebne, by pasować do konfiguracji. Jeśli ktoś zmienił SKU maszyny wirtualnej w portalu, zwykły terraform plan pokaże zmianę, która ją cofa. Inżynier przeglądający plan może nie zdawać sobie sprawy, że to jest naprawa dryfu, a nie nowa zmiana.
terraform plan -refresh-only robi tylko pierwszą część: odświeża stan i pokazuje, co zmieniło się w Azure, bez obliczania delty konfiguracji. Wynik polecenia mówi dokładnie, co uległo dryfowi i w jakim kierunku, bez mieszania z zamierzonymi zmianami. To właściwe narzędzie do audytu dryfu.
| # Audit drift without mixing with configuration changes terraform plan -refresh-only # If drift is intentional (e.g. ops team correctly resized a VM): terraform apply -refresh-only # This updates state to match reality no infra changes, just state sync # Check plan exit code in CI (0 = no changes, 1 = error, 2 = changes present) terraform plan -refresh-only -detailed-exitcode EXIT_CODE=$? if [ $EXIT_CODE -eq 2 ]; then echo “Drift detected” && send_alert fi |
Do ciągłego wykrywania dryfu w skali uruchamiaj zaplanowane plany w CI co kilka godzin dla wszystkich workspace’ów. Plan, który kończy się kodem 2, oznacza, że dryf istnieje i ktoś musi go przejrzeć. Koszt uruchomienia planu tylko do odczytu względem Azure jest pomijalny; koszt odkrycia dryfu trzy tygodnie później podczas incydentu — nie.
| WSKAZÓWKA: Parsuj wyjście planu poleceniem terraform show -json planfile | jq, by programatycznie kategoryzować zasoby z dryfem według typu, subskrypcji lub właściciela. Zbuduj dashboard z tego wyjścia zamiast czytać surowy tekst planu. W środowiskach z 200+ plikami stanu ręczny przegląd alertów dryfu nie skaluje się. Niektóre atrybuty dryfują zgodnie z oczekiwaniami w runtime: liczniki auto-skalowania, dynamiczne tagi Azure Policy, daty wygaśnięcia certyfikatów. Użyj lifecycle { ignore_changes = [tags, capacity] }, by wykluczyć te atrybuty z wykrywania dryfu. Zbyt szeroki ignore_changes maskuje prawdziwy dryf — ogranicz go do konkretnego atrybutu. |
Po wykryciu dryfu każde wystąpienie wymaga jednej z czterech odpowiedzi. Poniższa tabela mapuje decyzję na mechanizm i profil ryzyka.
| Odpowiedź | Kiedy stosować | Mechanizm | Ryzyko |
|---|---|---|---|
| Zaakceptuj dryf | Ręczna zmiana była celowa i poprawna; zaktualizuj stan do rzeczywistości | terraform apply -refresh-only | Niskie. Tylko aktualizuje stan, bez zmian infrastruktury. |
| Napraw dryf | Ręczna zmiana była błędna; przywróć pożądany stan zdefiniowany w kodzie | terraform apply | Średnie. Niszczy ręczną zmianę. Najpierw potwierdź plan. |
| Ignoruj trwale | Atrybut zasobu zmienia się dynamicznie w runtime (tagi, liczniki skalowania) | lifecycle { ignore_changes = […] } | Niskie przy precyzyjnym zakresie. Wysokie przy nadużyciu – maskuje prawdziwy dryf. |
| Importuj jako celowy | Zasób został utworzony poza Terraform; obejmij go zarządzaniem | blok import (v1.5+) z -generate-config-out | Średnie. Wygenerowana konfiguracja wymaga przeglądu przed apply. |
Najczęściej nadużywana odpowiedź to terraform apply bez dokładnego przejrzenia wyjścia planu. Gdy dryf konfiguracji narastał przez tygodnie, zwykły apply może zniszczyć ręczne zmiany, które były poprawne i celowe. Zawsze najpierw użyj -refresh-only, by zobaczyć, co się zmieniło, a następnie zdecyduj, czy zaakceptować, czy naprawić.
Odpowiedź z blokiem import (objęcie niezarządzanych zasobów kontrolą Terraform) zasługuje na szczególną uwagę w środowiskach enterprise. Flaga terraform plan -generate-config-out=generated.tf, wprowadzona w Terraform 1.5, automatycznie generuje konfigurację zasobu z istniejącego zasobu Azure. To najszybsza ścieżka od dryfu pokrycia do pełnego pokrycia IaC, ale wygenerowana konfiguracja zawsze wymaga przeglądu.
| WSKAZÓWKA: Przy używaniu -generate-config-out na zasobach Azure wygenerowana konfiguracja często zawiera atrybuty takie jak location jako zakodowana na stałe wartość zamiast zmiennej i może zawierać atrybuty tylko do odczytu powodujące błąd planu.Po wygenerowaniu uruchom terraform plan i szukaj błędów ’Values for these provider attributes cannot be configured’ — te atrybuty trzeba usunąć z wygenerowanej konfiguracji, a nie naprawiać. |
Korporacyjne bazy kodu Terraform w końcu wymagają refaktoryzacji: moduły są reorganizowane, konwencje nazewnictwa się zmieniają, workspace’y są dzielone w miarę wzrostu zespołów. Każda z tych operacji wymaga zmian stanu. Stare podejście to terraform state mv uruchamiany ręcznie w terminalu, bez śladu w kontroli wersji i bez procesu przeglądu. Dostępny jest teraz lepszy zestaw narzędzi.
| Narzędzie | Co robi | Wymaga | Ograniczenie |
|---|---|---|---|
| terraform state mv | Przenosi adres zasobu w pliku stanu imperatywnie | Terraform 1.0+ | Nie jest w gicie, nie przeglądane w PR. Między stanami tylko z flagą -state-out. |
| moved block | Deklaratywne przenoszenie/zmiana nazwy w tym samym pliku stanu | Terraform 1.1+ | Tylko ten sam stan. Brak cross-workspace. Brak logiki warunkowej. |
| blok import + generate-config-out | Importuje niezarządzany zasób do stanu z auto-generowaną konfiguracją | Terraform 1.5+ | Wygenerowana konfiguracja wymaga ręcznego oczyszczenia. Jednorazowe per zasób. |
| removed block | Usuwa zasób z zarządzania bez niszczenia go | Terraform 1.7+ | Nie przenosi zasobu do innego stanu. Użyj przed usunięciem bloku zasobu. |
| tfmigrate | Operacje na stanie jako deklaratywny HCL, przyjazny GitOps | Zewnętrzny binarny | Narzędzie firm trzecich. Dodaje zależność spoza ekosystemu HashiCorp. |
moved block (Terraform 1.1+) to właściwe narzędzie do zmiany nazwy zasobów lub przenoszenia ich między modułami w tym samym pliku stanu. Należy do konfiguracji Terraform, jest przeglądany w pull requeście i jest stosowany automatycznie przy następnym planie/apply. Żadnych poleceń w terminalu, żadnej ręcznej manipulacji stanem.
| # Rename a resource (added to main.tf, reviewed in PR) moved { from = azurerm_virtual_network.vnet to = azurerm_virtual_network.hub_vnet } # Move resource into a modulemoved { from = azurerm_subnet.gateway to = module.hub_network.azurerm_subnet.gateway } # Chain moves for multi-step refactors (all versions applied in sequence) moved { from = azurerm_virtual_network.network to = azurerm_virtual_network.vnet } moved { from = azurerm_virtual_network.vnet to = module.hub_network.azurerm_virtual_network.vnet } |
Utrzymuj bloki moved w bazie kodu, dopóki nie masz pewności, że wszystkie pliki stanu we wszystkich środowiskach zostały zaktualizowane. We współdzielonym module usuń je przy następnym major version bumpie. Nigdy nie edytuj istniejącego bloku moved po jego zastosowaniu — utwórz nowy z łańcuchem od bieżącego adresu.
Przed Terraform 1.7 usunięcie bloku zasobu z konfiguracji powodowało, że terraform apply niszczył zasób. removed Blok zmienia to: jawnie wyrejestrowuje zasób ze stanu bez niszczenia powiązanej infrastruktury. Użyj go, gdy zasób jest przekazywany innemu zespołowi, migrowany do innego pliku stanu lub po prostu powinien przestać być zarządzany przez Terraform.
| # Stop managing this resource without destroying it removed { from = azurerm_resource_group.legacy_rg lifecycle { destroy = false } } |
moved Blok nie może przenosić zasobów między plikami stanu. Dla migracji cross-state opcje to: terraform state mv (ręczny, imperatywny), kombinacja bloków import+removed (deklaratywna, ale dwuetapowa) lub tfmigrate (narzędzie firm trzecich, natywne dla GitOps).
tfmigrate zapisuje operacje na stanie jako deklaratywny HCL, commituje je do gita i stosuje jako sekwencję. Oznacza to, że migracje stanu są przeglądane w pull requestach, mogą być wykonywane na sucho bez wpływu na zdalny stan i są powtarzalne. Dla zespołów zarządzających 50+ plikami stanu ma to znaczenie: migracje stanu bez rekordu w gicie to zobowiązanie compliance i debugowania.
| # tfmigrate_split_network.hcl reviewed in PR, applied in CI migration “multi_state” “split_network_module” { from_dir = “platform/hub” to_dir = “platform/network” actions = [ “mv azurerm_virtual_network.hub module.hub_network.azurerm_virtual_network.hub”, “mv azurerm_subnet.gateway module.hub_network.azurerm_subnet.gateway”, ] } |
| WSKAZÓWKA: Przed każdą migracją cross-state uruchomterraform state pull > backup_$(date +%Y%m%d_%H%M%S).tfstate w obu workspace’ach źródłowym i docelowym. Wersjonowanie blobów pozwala odzyskać dane, ale posiadanie lokalnej kopii z sygnaturą czasową nic nie kosztuje i eliminuje jedną zmienną z procesu odzyskiwania. Aby skontrolować zawartość pliku stanu bez uruchamiania planu: terraform state pull | jq ’.resources[].type’ | sort | uniq -c | sort -rn Zwraca zestawienie typów zasobów według liczby wystąpień, przydatną przy decydowaniu o podziale dużego pliku stanu. |
Plik stanu Terraform rośnie liniowo wraz z liczbą zarządzanych zasobów. Plany stają się wolniejsze, równoległe operacje apply wchodzą w konflikty, a zmiany zasobów jednego zespołu blokują potok innego. Właściwy moment na podział to ten, zanim pojawią się te objawy, nie po.
Granica podziału powinna podążać za własnością, nie typem zasobu. Podział według typu zasobu tworzy zależności cross-state, które są trudne w obsłudze. Podział według granicy zespołu lub produktu oznacza, że każdy zespół może planować i stosować zmiany niezależnie.
Schemat dzielenia pliku stanu bez przestojów:
Do współdzielenia danych cross-state po podziale źródło danych terraform_remote_state może odczytywać wyjścia z innego pliku stanu. Używaj tego oszczędnie: twarde zależności między plikami stanu tworzą sprzężenie, które podważa cel podziału. W miarę możliwości współdziel dane przez ID zasobów Azure i konwencje nazewnictwa zamiast wyjść stanu.
| WSKAZÓWKA: Gdy plik stanu urósł do 50+ zasobów, a czas planu przekracza trzy minuty, czas na podział. terraform state pull | jq ’.resources | length’ podaje liczbę zasobów. Czas planu powyżej pięciu minut w CI to problem produktywności zespołu, który się kumuluje dziennie — dziel wcześnie. |
Problem inżyniera portalu. W każdym korporacyjnym wdrożeniu Azure jest co najmniej jedna osoba z dostępem Owner do subskrypcji, która regularnie wprowadza zmiany przez portal. Reguły bezpieczeństwa sieci otwarte podczas incydentów i nigdy nie zamknięte. Rozmiary maszyn wirtualnych zmieniane bez zlecenia zmiany. Tagi aktualizowane ręcznie. Właściwa odpowiedź to nie argument o procesach — to terraform plan -refresh-only według harmonogramu, z wynikami publikowanymi na kanale Slack. Widoczność zmienia zachowanie szybciej niż polityki.
Wygenerowana konfiguracja z -generate-config-out nie jest gotowa na produkcję. Flaga generuje plik konfiguracyjny Terraform, który importuje zasób bez niszczenia go, ale wygenerowany HCL konsekwentnie zawiera atrybuty tylko do odczytu lub obliczeniowe. Zastosowanie bez przeglądu powoduje w najlepszym przypadku błędy planu, a w najgorszym — nieoczekiwane modyfikacje. Traktuj wygenerowaną konfigurację jako pierwszy szkic wymagający oczyszczenia.
Force-unlock jest nieodwracalny przy złym ID blokady. Gdy używasz terraform force-unlock, zwalnia dzierżawę bloba według ID blokady. Jeśli odblokujesz zły workspace (częste w monorepo z podobnymi ścieżkami plików stanu), możesz odblokować stan, w którym aktywnie działa apply w CI. Efekt: równoległe zapisy do tego samego pliku stanu, co może prowadzić do uszkodzenia. Zawsze potwierdzaj ID blokady, workspace i kto trzyma blokadę przed wymuszonym odblokowaniem.
Przeniesienia cross-state psują moved blok. Zespoły przyzwyczajone do bloku moved dla refaktoryzacji w tym samym stanie czasem próbują użyć go dla operacji cross-state i napotykają mylący błąd: 'The moved block refers to a resource not in this configuration.’ moved Blok działa tylko w obrębie jednego pliku stanu. Dla przeniesień cross-state właściwy schemat to removed (źródło) + import (cel) lub tfmigrate dla bardziej złożonych przeniesień.
Rozmiar pliku stanu powoduje limit czasu planu w dużych subskrypcjach. Plik stanu zarządzający 300+ zasobami w subskrypcji Azure ze złożoną siecią może osiągać limity czasu planów — nie z powodu Terraform, ale dlatego że provider AzureRM wykonuje setki wywołań API podczas fazy odświeżania. Ograniczenie prędkości Azure API włącza się podczas tych dużych odświeżeń. Naprawa: podziel plik stanu przed osiągnięciem tego limitu. Sygnał ostrzegawczy: czas planów rośnie z tygodnia na tydzień bez dodawania nowych zasobów.
terraform plan -refresh-only odczytuje bieżący stan zasobów z Azure i pokazuje, co zmieniło się od ostatniego apply, bez obliczania, co Terraform musi zrobić, by pasować do konfiguracji. terraform plan robi obie rzeczy: odświeża stan i oblicza deltę konfiguracji. Używaj refresh-only do audytu dryfu; używaj zwykłego planu do decyzji wdrożeniowych.
Używaj bloku moved do wszystkich refaktoryzacji w tym samym stanie w Terraform 1.1+. Jest deklaratywny, można go przeglądać w PR i żyje w gicie. Używaj terraform state mv tylko gdy musisz przenosić zasoby między różnymi plikami stanu (cross-state), czego moved blok nie potrafi. terraform state mv powinno się traktować jako ostateczność, nie rutynowe narzędzie.
Użyj bloku import (Terraform 1.5+) z terraform plan -generate-config-out=generated.tf. Generuje to konfigurację zasobu odpowiadającą istniejącemu zasobowi Azure. Przejrzyj i oczyść wygenerowany HCL, następnie uruchom terraform apply. Zasób jest importowany do stanu bez zmian infrastruktury. ID zasobu Azure wymagane do importu jest dostępne z az resource show lub z panelu Properties portalu Azure.
Najpierw sprawdź status dzierżawy blob w portalu Azure lub poleceniem az storage blob show –query 'properties.lease’. Upewnij się, że żaden aktywny proces Terraform nie trzyma blokady. Następnie użyj terraform force-unlock <LOCK_ID> (ID blokady jest widoczny w komunikacie błędu przy jej nawiązaniu) lub zwolnij dzierżawę bloba bezpośrednio przez az storage blob lease break. Nigdy nie wymuszaj odblokowania bez potwierdzenia, że proces blokujący nie żyje.
removed Blok (Terraform 1.7+) usuwa zasób ze stanu Terraform bez niszczenia powiązanej infrastruktury, gdy ustawione jest destroy = false. Użyj go przed usunięciem bloku zasobu z konfiguracji, gdy chcesz przestać zarządzać zasobem, ale pozostawić go działającym. Bez bloku removed usunięcie bloku zasobu powoduje, że Terraform niszczy zasób przy następnym apply.
Dziel według własności i obszaru wpływu awarii, nie według typu zasobu. Każdy zespół powinien mieć jeden plik stanu na środowisko (dev/stage/prod) dla zasobów, którymi włada. Pliki stanu platformy lub sieci powinny być własnością zespołu platformy i konsumowane przez inne zespoły przez wyjścia remote state lub przez współdzielone konwencje nazewnictwa. Unikanie jednego pliku stanu dla całej strefy lądowania eliminuje wąskie gardło i jeden punkt uszkodzenia dla wszystkich zespołów.
Trzymaj je, dopóki wszystkie pliki stanu we wszystkich środowiskach nie zostaną zaktualizowane i dopóki masz pewność, że nikt nie używa wersji Terraform starszej niż ta, w której bloki zostały wprowadzone. Dla współdzielonych modułów – do następnego major version bumpa. Dla kodu aplikacji – przez co najmniej jeden cykl wydania. Zbyt wczesne usunięcie powoduje, że terraform plan pokazuje parę destroy/create dla zasobów, których wpis stanu nigdy nie został zaktualizowany.
Zarządzanie stanem to infrastruktura. Traktuj to tak od pierwszego dnia: izolowane konto storage, uwierzytelnianie oparte na Entra, wersjonowanie blobów, miękkie usuwanie włączone. To ustawienia, które umożliwiają odzyskanie, gdy coś pójdzie nie tak. Bez nich uszkodzony plik stanu to kryzys.
Dryf jest nieunikniony. Pytanie brzmi, jak szybko go wykryjesz i co z nim zrobisz. Zaplanowane uruchomienia terraform plan -refresh-only z monitorowaniem kodu wyjścia to tania warstwa wykrywania, którą większość zespołów pomija do pierwszego dużego incydentu z dryfem. Wbuduj to w CI, zanim będziesz tego potrzebować.
Zestaw narzędzi do manipulacji stanem znacząco się poprawił: moved blok (v1.1) dla refaktoryzacji w tym samym stanie, import blok z -generate-config-out (v1.5) do objęcia istniejących zasobów zarządzaniem, removed blok (v1.7) do czystego wyrejestrowania. terraform state mv jest teraz narzędziem ostateczności, nie rutynowym poleceniem. Jeśli Twój zespół nadal sięga po nie domyślnie, zaktualizuj podręcznik. Granice plików stanu definiują autonomię zespołu. Plik stanu, wobec którego zespół nie może uruchomić planu bez blokowania innego zespołu, to wąskie gardło. Dziel wcześnie, według linii własności, zanim czas planowania stanie się codzienną skargą
