Historia
https://piekielni.pl/88630 przypomniała mi:
Pracowałem kiedyś w firmie robiącej oprogramowanie wewnętrzne dla dostawcy usług internetowych. Program ten odpowiadał (między innymi) za włączanie i wyłączanie usług klientom.
W nowym wdrożeniu miał być bajer, że jeśli ktoś ma w systemie ustawioną datę wygaśnięcia umowy - system automatycznie zdezaktywuje mu usługę (wcześniej wszystko było ręcznie).
Wszystko przeszło przez testy wewnętrzne, klienckie i nadeszła noc wdrożenia. O godzinie 1 w nocy kolega odpowiedzialny za ten system dostał sygnał od adminów, że włączają nową wersję, patrzy więc w logi...
System zdezaktywował usługę jednemu użytkownikowi, drugiemu, trzeciemu... Zanim został awaryjnie wyłączony poszło około 300 dezaktywacji.
Okazało się, że system nie sprawdzał, czy data wyłączenia usługi nadeszła, tylko czy jest ustawiona w ogóle. Zaczął więc wyłączać usługi wszystkim, którzy mieli umowy terminowe.
Niestety tutaj nie wystarczyło przywrócić bazy danych. Wyłączenie i włączenie usługi polega na wysłaniu odpowiedniego sygnału do fizycznego urządzenia. Tyle dobrze, że system wypisywał co i komu faktycznie wyłącza. Ręczne przywracanie usług zajęło (już całemu zespołowi) resztę nocy.
Instancja testowa? UATy? A po co to komu? :D
Odpowiedz@Grav: przeszło przez wszystko :D Zarówno testerzy nasi jak i klienta przetestowali, że faktycznie usługa się deaktywuje jak ustawi się datę na już. Że dezaktywuje się już, jak ustawisz datę na za pół roku - nikomu nie przyszło do głowy sprawdzenie takiego testcase.
OdpowiedzZmodyfikowano 1 raz. Ostatnia modyfikacja: 15 października 2021 o 14:23
@niepodam: A no to w takim razie należy potencjał testing teamu uwolnić na rynek pracy :D
Odpowiedz@niepodam: podaję hasło: regresja :D
Odpowiedz@niepodam A zwyczajnie UT-ki? Tak samo testerzy tu zawalili, jak i programiści.
Odpowiedz"(...)jeśli ktoś ma w systemie ustawioną datę wygaśnięcia umowy - system automatycznie zdezaktywuje mu usługę" - czyli działa zgodnie ze specyfikacją....
Odpowiedz@SirCastic: nie zrozumiałes, jeśli jest ustawiona data wygaśnięcia umowy (np. za rok) to system odcina od razu, nieważne ile umowa jeszcze ma trwać,
OdpowiedzOsobom bez większego doświadczenia w projektach najpewniej narzuci się najprostsze pytanie: kto zatrudnił przygłupa po stronie analityka biznesowego i/lub programisty. Ale można też zapytać kto i jak: - zdefiniował i zapisał wymagania biznesu (osobiście widziałem nie takie rzeczy i to potwierdzane przez biznes) - zaprojektował przypadki testowe - przeprowadził (realnie) UAT-y (znam przypadki UAT-ów przeprowadzonych na korytarzu, wpisując w rubryki od góry do dołu "ok";) Patrząc na historię to na 90% ktoś zlecający zapomniał, że istnieją w firmie usługi terminowe. Nie powiedział o tym dostawcy, zapewniając, że jak data jest to znaczy, że do wyłączenia.
OdpowiedzZmodyfikowano 2 razy. Ostatnia modyfikacja: 15 października 2021 o 16:50
OdpowiedzZmodyfikowano 1 raz. Ostatnia modyfikacja: 15 października 2021 o 17:02
@ja_2: specyfikacja była OK, o ile dobrze pamiętam programista popierdzielił coś w implementacji - byłem wtedy w innym projekcie, więc kodu tego nie widziałem. Na logikę wystarczy odwrotnie postawiony znak większości, wtedy deaktywacja idzie dla wszystkich przyszłych dat zamiast minionych.
OdpowiedzCzyżby ISP to pomarańczowi? Bo mi ostatnio tak koło pierwszej w nocy właśnie zepsuło neta.
Odpowiedz@Aqaqq: tak, ale zanim jeszcze zostali na pomaranczowych przemianowani - jakieś 8 lat temu :)
OdpowiedzSłaba to firma programistyczna być musiała, co na szybko nie umiała naskrobać procedury "wyślijmy aktywację wszystkim wyłączonym" (bo taki znacznik musiał być, a gdyby się rozjechało - po prostu wszystkim z umową terminową). Takie funkcje z ręki pisze się i odpala w 5 minut, a nie resztę nocy.
Odpowiedz@yfa: Chyba mało wiesz o pracy w wielkim korpo, gdzie na każdą pierdółkę musisz mieć dupochron. Do tego dochodzi to, że wszelkiej maści pracownicy obsługi klienta muszą mieć łatwy, zrobiony na zasadzie czytelnego GUI, dostęp do danych klientów i do tego co się dzieje z ich kontem. Jeśli w tle będzie latał jakiś losowy skrypcik napisany na kolanie, to może nadpisywać zmiany dokonane ręcznie przez pracowników, którzy nawet nie będą wiedzieli jak to się stało. Potem osoba odpowiedzialna za skrypt odejdzie, nawet tego nie udokumentuje, a po następnej awarii masz katastrofę z odtwarzaniem tego jak to wszystko działa. Nie, jak się robi automatyzację w ramach istniejącego rozwiązania, to nie stawia się dupnych skryptów w 5 minut, tylko dokumentuje się listę dependencies, konsultuje ze wszystkimi, którzy z tego rozwiązania korzystają, żeby się upewnić, że ich praca się przez to nie wywali, pisze ten śmieszny, 5-minutowy kawałek kodu, wprowadza się go na instancję testową, testuje wszystkie wcześniej znalezione dependencies, a potem dopiero odpala na prod. Przez takie podejście, jakie opisałeś, mieliśmy klienta (naprawdę dużego, i to z branży powiązanej z ludzkim życiem), którego dokumentacja sprowadzała się do "mamy 7 inżynierów, którzy to wszystko ogarniają", no tylko zanim przyszło co do migracji, to 6 z nich rzuciło robotę, więc jedyne, co nam pozostało, to wyłączanie po kolei wszystkich kont serwisowych i patrzenie co klęknęło.
Odpowiedz@yfa: dodaj do tego co Grav napisał brak API restowego (system z czasów, gdzie modne były JSF), pierdyliard opcji dla każdej usługi i z 5 minut robi ci się ładne parę godzin. Do tego taki skrypt fajnie by przetestować, żeby fakapu nie pogłębić. A na rano wszystko ma działać, zanim klienci się obudzą i zaczną dzwonić z pogróżkami.
Odpowiedz@niepodam: wiem za to dużo o DR. Jak się nie umie zrobić prawidłowo migracji, w tym zrobić rollbacku, to jest się po prostu słabą firmą programistyczną. @Grav - chyba nie zrozumiałeś, co ten skrypt miałby zrobić. Jednorazowo wykonać provisioning urządzeń, które zostały rozkonfigurowane, a nie "latać sobie w tle". Kompletnie nie rozumiesz, że takie rozwiązanie nie jest częścią systemu i nie można go sobie w sandboxie testować, JEŻELI WCZEŚNIEJ słaba firma programistyczna o tym nie pomyślała - a zmiany JUŻ poszły na produkcję i wyszły POZA system (do zewnętrznych urządzeń). Damage is done. Testbed systemu powinien obejmować wszystkie interconnecty. Pomijając już fakt, że podczas wdrożenia powinno się aktywować throttling oraz audyt wysyłanych poleceń i w razie konieczności wcisnąć przycisk 'stop'. I teraz masz dwa wyjścia - puścić sztab ludzi, żeby tydzień to ręcznie naprawiali, w międzyczasie pomijając masę danych do przywrócenia i wprowadzając piedryliard błędów, które będą się odbijały czkawką przez następne pół roku, albo zapłacić specjaliście te 5k za nockę, żeby naprawił choćby od backendu. Naczelna i oczywista reguła w przetwarzaniu danych brzmi: człowiek nigdy nie wprowadzi ich prawidłowo; automatyzuj. Na etapie gorącego fuckupu to te wszystkie projektowe mądrości i magiczne zasady można sobie w buty wsadzić, trzeba się było do nich stosować wcześniej. @niepodam - pierdyliard opcji? Stosujesz regułę Pareto: włączasz usługi podstawowe i masz 80% roboty i telefonów z głowy. A jeżeli masz faktycznie bardzo ciężkie interfejsowanie z jakimś archaicznym g* systemem, to po prostu należy zrobić jakieś detention proxy celem opóźnienia wysłania danych względem commitu w systemie. Poza tym również kompletnie nie zrozumiałeś idei - skryptu nie piszesz po to, żeby na backendzie grzebać i rozsyłać bezpośrednio komunikaty do zewnętrznych urządzeń, ale żeby na podstawie audit logów wycofać wprowadzone zmiany. Więc doskonale wiesz, do jakich parametrów trzeba wrócić, a do wykonania używasz dokładnie tych samych metod, jakie zostałyby użyte po ręcznym kliknięciu przez człowieka we frontendzie, zatem w żaden sposób nie zagrażasz spójności danych i koherencji zewnętrznych systemów. I nawet jeśli ten inżynier będzie to pisał pół dnia, to na następny dzień wszystko będzie w stanie wyjściowym, w przeciwieństwie do danych przewalonych siłami ludzkimi, bo tam będzie 20% błędów.
Odpowiedz@yfa: problem w tym, że dla każdego indywidualnego klienta "usługi podstawowe" zależą od możliwości sprzętowych. Pierwszy strzał z API to pytanie o to, czy klient jest obsługiwany przez urządzenie Huawei, Siemensa, Alcatela czy czego tam jeszcze, następnie na podstawie tego generowany widok z odpowiednimi opcjami. Warstwy abstrakcji nad tym brak. I tak, zgadzam się, że dałoby się to napisać na podstawie audit loga, kwestia: czy rano chcesz mieć max 20% wk*nych klientów z powodu błędów ludzkich (a faktycznie dużo mniej, sporo się nie skapnie w sobotę rano, że nie działa coś za co zapłacili, skoro ogólnie Internet działa) czy 100% bo nie będzie działać nic, a programista wciąż kończy skrypt naprawczy.
Odpowiedz@niepodam: usługa podstawowa to włączenie np. 100 Mb/s - klient nie ma sprzętu na to? Overbooking za duży wyjdzie? Weź nie żartuj... przecież mówisz pewnie provisioningu OLT-ów (Siemens znaczy Dasan?), a nie jakichś DSLAM-ów w muzeum. I to tylko w warstwie dostępowej, bo do CPE jest TR069, który konfig pobiera aktywnie. Ale żebyśmy mieli wspólny mianownik do tej rozmowy, to dla mnie: - brak warstwy abstrakcji to właśnie "słaba firma programistyczna" (i głupi klient), - programista, który nie zrobi tego w pół nocy to "słaba firma programistyczna". I nie "rano 20%", tylko "przez następne pół roku 20%". Bo danych, które ktoś w pośpiechu naklepie w systemie, nie ma kto i nikt nigdy już nie zweryfikuje. Klienci będą pisać reklamacje, a rozpatrujący je osobnicy będą patrzeli na dane z systemu, bo nikt treści umów już nie przeczyta. Ale serio, brak abstrakcji? To w jaki sposób ten operator migruje klientów przy zmianie sprzętu? Też ktoś ręcznie wyłącza, migruje i włącza usługę?
Odpowiedz