Estymacja czasu pracy

Kiedyś, na konferencji zespołu IT, padło ze strony managementu firmy takie oto zapytanie:

– Chłopaki! Za za dwa tygodnie zaczynamy wdrożenie naszego softu do naszego klienta, od poniedziałku zaczynamy testy (konferencja w piątek popołudniu). Proszę abyście w poniedziałek przedstawili nam, ile potrzebujecie czasu na naprawę błędów które wyjdą w trakcie tych testów.

Dobrą chwilę zajęło nam ochłonięcie, czy dobrze obczailiśmy o co tak właściwie chodzi… Mamy wyestymować, ile czasu zajmie nam naprawa błędów, które wyjdą w testach, które rozpoczną się w nadchodzący poniedziałek, podczas gdy mamy jeszcze parę funkcjonalności do dopisania…

łohoo…

Perełki pracy w międzynarodowym zespole IT

Zabierałem się za ten wpis od dłuższego czasu, wiele z perełek już pozapominałem, ale ostatnia przygoda przypomniała mi niektóre schematy podejścia do zarządzania pracą w zespole…

Otóż, let me explain…

Mamy sobie system, który pracuje na danych użytkowników, dane różnego rodzaju. Problem jest taki, że tych danych ciągle przybywa, a limit na serwerze wynosi 12TB, w tym momencie mamy dyski obciążone w 11TB, więc… za jakiś czas, utrzymywany system przestanie działać i nie będzie w stanie przyjmować nowych danych, anie nawet operować na już istniejących, ponieważ nie wygeneruje żadnego outputu. A więc, no jakby nie było… major issue!

Aby temu zaradzić, jakiś czas temu podjęliśmy kroki celem wdrożenia obsługi dumnie brzmiącej „Chmury”, innymi słowy – pliki będą pchane do CDN’a (na zewnętrzne serwery), które są tak fajnie skonstruowane,że nie mają „sufitu” w postaci limitu danych, pchamy ile wlezie przez API i nie zastanawiamy się ile tego jest – ew. jak koszty za utrzymanie CDN’a urosną, to będziemy się tym martwić – najważniejsze, że system przetrwa i nie zaliczy blackoutu.

No i dobra, taki był plan, klepiemy sobie tą integrację, testujemy to aby współpracowało z jednymi i drugimi danymi – w planie jest aby nowe rzeczy pchać do CDN’a, a stare obsługiwać po staremu, sukcesywnie przepychając je też do tego CDN’a, aby w końcu odciąć się od lokalnych dysków.

Jednak od jakiegoś czasu prezes zaczął mi płakać, że serwer jest przeciążony, bo wszystkie CPU pracują na granicy 100%, no i musimy coś z tym zrobić, bo jesteśmy overloaded! Oczywiście nie będę zliczał ile to razy wyciągał mnie telefonem z łóżka, bo system jest overloaded!

I owszem, obciążenie sięgało 100%, ale cały system działał gładziutko, Apache chodzi na najwyższym priorytecie, a co się da, jest pchane do backgroundu i wykonywane z niższymi priorytetami – dzięki temu, dla usera system zawsze działa płynnie. Różnica może być taka, że przy niskim obciążeniu dostanie maila z wynikiem po paru minutach, a przy dużym obciążeniu, po kilkunastu.

Ja tam bym się cieszył, jakby moje serwery pracowały przy obciążeniu zbliżonym do 100%, bo to by oznaczało, ze nie marnuję zasobów na serwer, który nie jest wykorzystywany. No ale kryzys, bo serwery są przeciążone i trzeba coś z tym zrobić…

Po paru takich razach zacząłem ignorować ten płacz, tym bardziej, że w planie mamy optymalizację i podział tasków na kilka maszyn, więc nie widziałem sensu zabawy z serwerem, skoro i tak zaraz będziemy całość kroić.

No ale nie, prezes „dogadał” się z naszym usługodawca, i dostaniemy jakiegoś „potwora”, który będzie wymiatał i rozwiązywał problemy userów, nim jeszcze się pojawią. Rzekomo miał to być jakiś super serwer, tylko dla nas, na nasze zlecenie. Finalnie okazało się, ze będzie to po prostu maszyna ze standardowej ofert (w tym sensie, że nic nie będzie zrobione pod nas indywidualnie).

No dobra, szybko ASAP, trzeba postawić nowy serwer! Bo użytkownicy skarżą się, że system działa wolno!

No to odpalam nowy serwer, rozpoczynam konfigurację w panelu usługodawcy… serwerek bardzo przyjemny, nie powiem… 250GB SSD, 16 CPU cores, 60GB RAM… no.. coś z tego będzie. Cena za miesiąc, przekroczyła magiczne 10k… ok, prezes płaci…

No to zaczynamy konfiguracje, serwer postawiony, powoli konfiguruję Apache’a, nagle prezes mi pisze z satysfakcją w palcach, że widzi, ze nowy serwer już działa! Taaak… pewnie zobaczył domyślną stronę Apache’a po tym jak odblokowałem traffic na porcie 80, eh…

[minął jeden dzień]

Po powrocie ze świątyni dumania, troszkę zmartwiony, rozpoczynam rozmowę z prezesem, bo jest problem… co z naszymi danymi? Teraz dane są na starym serwerze. Jak postawimy nowy serwer, to trzeba będzie te dane przecież skopiować. Kopiowanie danych zajmie pewnie z miesiąc (nim rsync przepcha je przez infrastrukturę serwerowni). W tym czasie, dalej będziemy siedzieć na starym serwerze, a za nowy trza będzie bulić. Po miesiącu trzeba będzie ponownie odpalić rsync’a, coby dociągnął to co się w ciągu miesiąca zmieniło i przy dobrych wiatrach nowy serwer zacznie śmigać. Ok… ale, ale… chwilka… czy nie jest problem z ilością danych? przecież na nowym serwerze też tylko max 12TB zmieścimy… No dobra, czyli, trzeba wrócić do CDN’a, no ale ten? To kiedy pchamy dane do CDN’a, bo się pogubiłem…

Czyli – pauzujemy robotę z CDN’em, konfigurujemy serwer, rozpoczynamy kopiowanie plików na nowy serwer, a jak je przepchniemy, to dopiero wtedy zaczniemy je znowu pchać do CDN’a? A może jednak lepiej od razu dokończyć CDN’a, i zacząć pchać stare dane do CDN’a, jak już wszystko przepchamy, to postawimy nowy serwer i przepniemy się w ciągu jednej nocy, bo i pliki i baza są na zewnętrznych usługach?

Prezes myśli, myśli… I wyskakuje mi z innym zadaniem, że trzeba teraz zostawić CDN, zostawić na wpół skonfigurowany serwer i zająć się czyszczeniem danych!

Padłem…

Gwoli wyjaśnienia, problem czyszczenia danych to problem, nad którym pracowaliśmy z jakieś pół roku temu, bo większość danych, user wykorzystuje tylko raz, pcha na serwer, bierze coś od nas, robi sobie z tego jakieś misz-masz, bierze swój output i znika, nigdy więcej nie wracając do starych danych. Więc dobrze byłoby te dane czyścić. No i był taki task, Cleaning… który został porzucony po bodajże tygodniu roboty, bo „są inne, ważniejsze rzeczy”.

Tak, i teraz wielki powrót do Cleaningu, a żeby było ciekawiej, prezes stwierdził, że ostatnio spędziłem nad tym dużo czasu, więc teraz „weź godzinę i sprawdź jak to dostosować, żeby teraz działało”…

Nie wiem k***a o co mu teraz chodzi? Stare skrypty pewnie nadają się do wywalenie, bo przez te pół roku doszło tyle zmian w systemie, że 3/4 tego jest już nieaktualne. Zamiast dokończyć to co zaczęte i rozgrzebane, to nie… zarzuć wszystko i zmiataj do nowego taska…

Bieganie z oponą – pierwsze wrażenia

No dobra, pierwszy kilometr z oponą już za mną, za wiele tego nie było, ale opiszmy co udało się zapamiętać.

Wnioski na przyszłość:

  • lina 2m w zupełności wystarcza
  • nie warto oszczędzać na detalach
  • uprząż nie do końca działa prawidłowo
  • większe opony

Uciąłem 4 m liny, bałem się, aby nie uciąć zbyt mało 🙂 ale lekko przedobrzyłem, 2m w zupełności wystarcza, przy dłuższej linie trochę dziwnie czuć opór generowany przez oponę, no i jest dużo większa inercja na zakrętach czy powrocie.

Co do oszczędzania na detalach, jeden ekspres kupiłem profesjonalny do wspinaczki, drugi, gdzieś wygrzebałem w skrzyni ze skarbami. Niestety ten mniejszy słabo spełnił swoją rolę, „kaleczył” linę, trudno było go dobrze wpiąć a przy dwóch oponach, samoczynnie się wypiął podczas biegu :-/

Nie znalazłem wiele materiałów w sieci na temat biegania z oponą, natomiast tam to co znalazłem dotyczyło podpinania opony do pasa. W swoim rozwiązaniu chciałem zastosować inne rozwiązanie – podpiąć oponę do uprzęży założonej na górnej części tułowia. Założeniem było to, że w takiej sytuacji będą również pracować mięśnia brzucha. Czy udało się zrealizować to założenie? Trudno powiedzieć, za krótko biegałem aby móc stwierdzić zmęczenie tych mięśni, jednak największą wadą uprzęży było jej wykorzystanie wbrew przeznaczeniu – uprząż przeznaczona jest do noszenia na plecach, tymczasem ja montowałem ją na odwrót, aby zaczepy były na plecach, efekt był taki, że taśmy krzyżowały się wysoko, tuż pod szyję, delikatnie przyduszając podczas biegu, poza tym wydaje mi się, że gdybym pobiegał 2x więcej / dłużej, to pojawiły by się obtarcia na obojczykach. Trzeba to rozwiązanie udoskonalić. Tu przydałoby się coś bardziej na kształt „pajączka”, z osobnymi uchwytami na każdą z rąk, coś co nie będzie się dodatkowo krzyżować na klatce piersiowej.

Nie wiedziałem czego się spodziewać po bieganiu z opona, więc na początek wybrałem sobie oponę od skutera i od ścigacza xD Tej od skutera to praktycznie nie dało się odczuć. Przy dwóch oponach było w porządku, ale dołożyłbym jeszcze ciut wagi. Następnym razem wezmę jakąś większą oponę od samochodu osobowego. Swoją drogą… ciekawe musi wyglądać trening z jakąś większą opona, np. taką z samochodu dostawczego 😀

Ogólnie jednak bieganie z oponą oceniam bardzo dobrze, gdyby nie odcisk na pięcie z poprzedniego treningu, to poszalałbym dłużej, ale bałem się aby nie zrobić sobie większej rany, co wykluczyłoby mnie z swobodnego poruszania się na tydzień. Opór jest znaczny i zmęczenie bardzo szybko narasta, co świetnie wygląda gdy nie ma za dużo czasu na trening, a chcemy się „sponiewierać” 🙂

Natomiast, wydaje mi się, że zacznę od szybkiego marszu, a dopiero potem przejdę do biegania, tak aby treningi z oponą wprowadzać płynnie a nie agresywnie.

 

Koszty:

  • Lina, 10m = 10zł
  • Karabinek = 20zł
  • Zużyta opona = 0zł