Najwięcej o architekturze systemu mówią jego realne awarie — kilka anonimowych historii typu „publish nadpisał cudzą wersję” i co z nich wynika na przyszłość.
Reszta tej książki opisywała mechanizmy w ich zamierzonym działaniu. Ten dodatek robi coś przeciwnego — pokazuje trzy anonimowe, uproszczone historie tego, co się dzieje, kiedy te same mechanizmy zawodzą w realnej produkcji, i jaki wniosek płynie z każdej z nich.
Dwóch artystów opublikowało tę samą postać w odstępie kilku sekund. Narzędzie publikujące (Rozdział 7) odczytało najwyższy istniejący numer wersji w folderze publish/, dodało jeden i zapisało wynik — dokładnie tak, jak zostało zaprojektowane. Problem: oboje odczytali ten sam, jeszcze nieaktualny numer, zanim którekolwiek z nich zdążyło zapisać swój wynik, więc oboje nadali swojej publikacji tę samą wersję. Druga zapisana wersja fizycznie nadpisała pierwszą na dysku. Wniosek: odczyt-i-inkrementacja numeru wersji musi być operacją atomową, wykonywaną przez jedno, centralne miejsce (serwer Perforce albo system śledzenia), nie przez każdy klient odczytujący ten sam folder osobno — dokładnie ten sam typ błędu, przed którym Rozdział 6 chroni blokadą przy edycji pojedynczego pliku, tylko przeniesiony na poziom nadawania numeru wersji.
Aktualizacja niepowiązanego narzędzia zmieniła nazwę jednego pola w API systemu śledzenia. Hook z Rozdziału 18, odpowiedzialny za powiadamianie działu riggingu o nowych publikacjach, odwoływał się do starej nazwy tego pola — zaczął cicho zawodzić przy każdym uruchomieniu, ale błąd trafiał do logu, którego nikt nie sprawdzał, bez żadnego alertu. Dział riggingu nie dostawał powiadomień przez ponad tydzień, zanim ktoś przypadkiem zapytał, czemu nikt nie reaguje na nowe publikacje. Wniosek: automatyzacja, która potrafi zawieść cicho, prędzej czy później zawiedzie cicho — hooki potrzebują własnego, aktywnego monitoringu błędów, nie tylko możliwości logowania ich gdzieś, gdzie nikt nie patrzy. To dokładnie ostrzeżenie z końca Rozdziału 18, tym razem jako realny, a nie hipotetyczny scenariusz.
Artysta zszedł z produkcji A i został formalnie usunięty z tego projektu w systemie śledzenia (Rozdział 8). Nikt jednak nie usunął jego dostępu do odpowiadającej ścieżki w Perforce (Rozdział 6) — te dwie warstwy uprawnień, opisane w Dodatku H, aktualizowane były ręcznie, przez dwie różne osoby, w dwóch osobnych krokach. Miesiąc później ten sam artysta, pracując już przy produkcji B, przez pomyłkę otworzył i zapisał plik z wciąż aktywnym dostępem do A, nadpisując zablokowaną wersję, którą zespół A uznawał za bezpieczną i zamrożoną przed dostawą. Wniosek: dwie niezależne warstwy uprawnień, które w teorii powinny być zsynchronizowane, prędzej czy później się rozjadą, jeśli synchronizacja jest ręczna — to zadanie dla automatyzacji z Rozdziału 18 (hook reagujący na usunięcie z projektu), nie dla checklisty, o której ktoś może zapomnieć.
Żadna z tych trzech awarii nie wynikała z niekompetencji którejkolwiek z zaangażowanych osób. Każdy mechanizm, który zawiódł, działał dokładnie tak, jak go zaprojektowano — problem polegał na tym, że rzeczywistość przestała spełniać założenie, na którym ten projekt się opierał: że odczyt i zapis wersji nigdy się nie nałożą w czasie, że hook, który raz zadziałał, będzie działać zawsze, że dwa niezależne systemy uprawnień ktoś będzie pamiętał aktualizować razem. Dobry pipeline nie eliminuje takich założeń całkowicie — to niemożliwe — ale sprawia, że kiedy któreś się złamie, awaria jest głośna i szybka do zdiagnozowania, zamiast cicha i odkrywana przypadkiem tydzień później.