Spowiedź admina. Rozmawiamy z ninja, który zarządza infrastrukturą IT dla klientów w chmurze

Zadanie administratora zajmującego się wdrażaniem, konfiguracją i opieką nad chmurą obliczeniową nie jest łatwe. Wymaga to nie tylko doświadczenia i umiejętności, ale też odpowiedniego przygotowania do pracy w ciężkich warunkach. Dla użytkownika końcowego, a nawet klienta korporacyjnego praca takiego admina jest często przezroczysta. Warto jednak uświadomić sobie, na czym polegają wyzwania stawiane przed takim ninja, jak właśnie Zbigniewem Kamińskim z Oktawave, z którym miałem okazję przeprowadzić poniższą rozmowę.

Piotr Grabiec, Spider’s Web: Zespół Migracyjnych Ninja, brzmi ciekawie, ale czym dokładnie się zajmujecie?

Zbigniew Kamiński, Oktawave: Zostaliśmy ochrzczeni ninja przez naszego szefa komunikacji, który pewnego dnia uświadomił sobie, że nasza praca wymaga ogromnego doświadczenia, nieprzeciętnej precyzji i skupienia, a przy okazji jest całkowicie przezroczysta. Wiesz, o co chodzi? Coś się dzieje, przeciętnemu obserwatorowi wydaje się, że to magia, ale tak naprawdę z drzewa powoli osunął się na linie ninja i wcisnął odpowiedni przycisk (śmiech). My właśnie to robimy - dbamy, by powierzone nam przez klientów serwery działały, jak gdyby nigdy nic.

Powierzone przez klientów?

No tak, duży klient najczęściej nie kupuje po prostu serwera, z którym próbuje sam sobie radzić. Oddaje go w ręce doświadczonych administratorów, czyli nas. My zaś dbamy o jego aktualizację, bezpieczeństwo, wydajność i architekturę.

Jak to się wszystko zaczęło?

Nasze szlify zdobyliśmy jako zespół utrzymania w K2 Hosting i to jest historia, której nigdy nie zapomnę. To doświadczenie najwyższej próby, ponieważ tam zawsze masz do czynienia z markami z pierwszych stron gazet. Wśród nich są lub byli operatorzy telekomunikacyjni, instytucje ubezpieczeniowe, korporacje i wiele innych. Za każdym razem opiekujemy się dużymi systemami informatycznymi obsługującymi ogromny ruch internetowy, więc cały czas działasz trochę jak chirurg.

Dziś to doświadczenie jest zlokalizowane nie tylko w K2 Hosting - dzięki ninja stało się dostępne dla wszystkich klientów chmury Oktawave. I to jest coś naprawdę fajnego.

Czyli duże i znane marki również korzystają z chmury?

Zdecydowanie tak. Coca-Cola, TUI, AVIVA czy Grupa Pracuj.pl - to tylko przykłady pierwsze z brzegu, o których możemy mówić.

Z jakiego typu problemami mierzysz się więc w codziennej pracy?

Praca w naszym dziale ma ten niewątpliwy plus, że codziennie trzeba mierzyć się z innymi problemami. Wynika to przede wszystkim z faktu, że środowiska, którymi opiekujemy się na co dzień lub te, które do nas migrujemy, w większości przypadków są od siebie bardzo odmienne. Oznacza to, że do każdej instalacji musimy podejść indywidualnie. Najczęściej jednak mamy do czynienia z "dostrajaniem" konfiguracji do potrzeb określonych rozwiązań aplikacyjnych. Nie nazwałbym ich więc problemami, ale raczej wyzwaniami.

Czy praca administratora to częściej praca w zespole czy raczej w pojedynkę?

Każdy mit o adminach sugeruje, że jesteśmy zarośniętymi nerdami, którzy coś tam sobie klepią na klawiaturze i żyją sami sobie (śmiech). Pewnie coś w tym jest, bo jednak gdy konfigurujesz konkretne środowisko lub gdy w pełnym skupieniu pracujesz nad danym zagadnieniem, to najczęściej robisz to w pojedynkę, więc tak to może pozornie wyglądać.

Jednak gdy utrzymujesz usługi w trybie 24/7/365, nie jesteś w stanie zrobić tego indywidualnie. Każdy z nas stara się więc wykonać swoja prace w ten sposób, by była oczywista dla reszty ekipy. To pierwszy przejaw człowieczeństwa, który u nas się pojawia! Nasz dział poszedł też krok do przodu, ponieważ nad wieloma projektami pracujemy w grupach. Dzielimy obowiązki pomiędzy siebie i dzięki temu powstają fajne rozwiązania.

Czy są zadania w Twojej pracy, które są wybitnie trudne i wymagają uwagi, bo każda pomyłka może być brzemienna w skutkach? Czy któryś obszar Twojej pracy można porównać do pracy mylącego się tylko raz sapera?

Odpowiem pytaniem na pytanie. Załóżmy, że dostaję od Was zlecenie, by zrobić jakieś przekierowanie, powiedzmy z http://www.spidersweb.pl na http://spidersweb.pl. Proste, prawda? Jednak siedzę rozkojarzony, cały czas ktoś mi krąży nad głową, a ja mam wklepać regułkę. Załóżmy dodatkowo, że przed momentem czytałem artykuł na http://chip.pl... Nie trzeba wiele, by wysłać czytelników do konkurencji i ściągnąć sobie na głowę gniew klienta. Oczywiście powyższy przykład może wydawać się banalny i śmieszny, ale chcę podkreślić, że w realizacji naszych zadań na każdym kroku niezbędne jest odpowiednie skupienie i rozwaga w wykonywanej pracy. Czasem czujemy się jak kontrolerzy lotów.

Jaki był największy, nie przebierając w słowach "fuckup", z którym musiałeś sobie poradzić?

99% usług, którymi zarządzamy, to usługi należące do dużych klientów. Powiedzmy to sobie jasno: tutaj nie ma miejsca na "fuckup". Każda nasza pomyłka, każdy nasz błąd może mieć odzwierciedlenie w dochodach osób, które nam zaufały.

W swojej karierze w Oktawave z pewnością zajmowałeś się najróżniejszymi zagadnieniami. Czy chciałbyś o jakiejś sprawie opowiedzieć coś więcej, jakiś case jest ciekawszy, nietypowy, wyjątkowy?

Jest kilka projektów, które zapadły mi w pamięć z różnych względów. Jeśli miałbym przytoczyć konkretne, to na uwagę na pewno zasługuje ostatni projekt realizowany dla Coca-Cola, który opisywaliście na łamach Spider's Web. Pod wymagania środowiska zastosowaliśmy mechanizmy redundancji instancji OCI zarówno dla plików aplikacji, baz danych, jak i serwerów pośrednich. Chociaż, gdy teraz się zastanawiam, to ten projekt zapadł mi w pamięć również z innego powodu. Wyobraź sobie, że sama specyfikacja kwestii bezpieczeństwa pod kampanię była opisana na 28 stronach. Generalnie był to więc projekt bardzo wymagający pod względem konfiguracyjnym, jak również i organizacyjnym.

Nie śmiej się, ale wiesz, co chcę jeszcze powiedzieć (śmiech). Często wracam też myślami do migracji Spider's Web do Oktawave. W dużej mierze dlatego, że to był jeden z pierwszych moich projektów migracyjnych (klasyczne rozwiązanie => chmura), ale wspominam często, jak siedzieliśmy z kolegą w nocy i - mając jedynie dostęp via FTP do Waszego starego hostingu - musieliśmy PHP shellem pakować katalog po katalogu foty Waszego serwisu, bo były problemy z kodowaniem polskich znaków w nazwach plików (śmiech). Oto życie admina w pełnej krasie! Takich nietypowych sytuacji jest wiele i każda migracja potrafi czymś zaskoczyć.

Co daje Ci chmura, a czego nie dawały Ci wcześniej dedyki?

Wygodę, szybkość, elastyczność, skalowalność i oszczędność. Chmura zdejmuje wiele ograniczeń, które posiadają dedyki. Osobiście uwielbiam chmurę za szybkość, z jaka mogę mieć nowy serwer. Kilka kliknięć w panelu i za chwilę można już coś "psuć" na nowej maszynie. Co więcej, chwilę później można mieć już tych maszyn kilka i pracować nad zestawieniem na nich replikacji albo po prostu zrobić testy porównawcze zachowania danej aplikacji w oparciu o różne systemy operacyjne, różne oprogramowanie itd.

Możesz też zlecić pewne operacje zaimplementowanym w Oktawave usługom takim jak Autoskaler, co nie jest możliwe przy korzystaniu z serwerów dedykowanych. Kolejna sprawa, bez której obecnie nie wyobrażam sobie swojej pracy, to możliwość migrowania maszyn na storage o różnych prędkościach (tzw. Tierach). Szybsze dyski pod duże bazy danych? Proszę bardzo, a wszystko to w ciągu kilku krótkich chwil.

Czuję też taką nerdowską dzikość serca, kiedy spotykam się z klientami i oni do mnie mówią: Zbychu, to jest dobre. Użytkownicy chmury cenią ją nie tylko z powodu oszczędności, ale chyba przede wszystkim przez wzgląd na elastyczność. Przykładowo, działy deweloperskie w łatwy sposób mogą odpalić sobie dowolne środowisko i tym samym wdrażać różne pomysły niemal od ręki.

W jakim kierunku powinien iść rozwój aplikacji i infrastruktury? Jak powinni myśleć jej twórcy?

W mojej ocenie powinni przestać myśleć monolitycznie o aplikacji, a zacząć ją rozbijać na komponenty i te komponenty oddawać do obsługi usługom w chmurze. Takich usług już dziś jest trochę (Bazy danych na szybkich dyskach OVS czy storage obiektowy OCS), a w przyszłości będzie ich jeszcze więcej. Deweloperzy muszą być gotowi na tę zmianę, bo ona np. w USA już zaszła, w Polsce przeżyje rozkwit za kilka lat.

Który CMS jest najbardziej problematyczny z Waszego punktu widzenia - jakiś własny czy któryś z ogólnie dostępnych, np. WordPress?

To jest trochę tak, jak mielibyśmy rozmawiać o tym, który język programowania jest mniej problematyczny: Perl czy Python? W znacznej mierze zależy to od tego, jak dane reguły, składnię i styl opanował i reprezentuje jego użytkownik. Generalnie, z naszego punktu widzenia najważniejsza jest dobra współpraca na linii admin - deweloper. Gdy na tej płaszczyźnie nie ma zgrzytów, to niezależnie od rodzaju CMS-a, gdy pojawi się jakiś problem, będzie łatwy do rozwiązania.

I nie ma tu znaczenia, czy pracujemy z CMS-ami dostępnymi publicznie, czy też autorskimi. Jasne, jeśli mówimy o oprogramowaniu takim jak WordPress, Magento czy Joomla!, w łatwy sposób można pozyskać wiele plug-inów dostępnych na te platformy. To niewątpliwie jest zaleta, jednak taka popularność oprogramowania ma też swoje minusy w postaci znacznie większej liczby wykrytych podatności i krążących w Sieci exploitów wykorzystujących dane luki. Tak, wiem, społeczność wychwytuje to luki i szybko je łata, ale często nie dotyczy to niestety plug-inów.

Na podstawie własnego doświadczenia, powiedz czy faktycznie pomiędzy Windows na Linux na serwerze jest taka wielka różnica?

A w jakim kontekście pytasz? Generalnie system operacyjny dobieramy pod konkretne wymagania danego projektu. Każdy ze wskazanych systemów posiada swoje plusy i minusy. Oczywiście, sposób zarzdzania się rożni, ale finalnie chodzi o niezawodność w działaniu usług klienta i tu mogę powiedzieć, że posiadamy serwery oparte o oba systemy operacyjne, których uptime jest liczony w setkach dni. Da się to osiągnąć na obu systemach.

Z Twojego doświadczenia, co częściej sprawia problem: maszyna, czy człowiek?

Kiedy utrzymujesz środowisko w pełni redundantne, to nawet w przypadku awarii fizycznych urządzeń, ciągłość świadczonych usług zostaje zachowana, a tym samym takie awarie mówiąc wprost - mniej bolą. Pamiętaj też, że nasz dział zajmuje się utrzymaniem usług klienckich na poziomie systemu operacyjnego. O infrastrukturę sprzętową Oktawave dba inny zespół administratorów, a jeszcze inny o platformę aplikacyjną (może kiedyś z nimi też porozmawiacie?), a więc nas bezpośrednio problemy sprzętowe nie dotyczą. Sprawia to, że częściej mamy do czynienia z problemami wywołanymi przez czynnik ludzki, choć rzeczywiście - tak jak i wszędzie - w Oktawave także zdarzają się niewielkie awarie, ale zazwyczaj w ciągu kilku minut są usuwane (może dlatego że koledzy od infrastruktury siedzą obok, śmiech) - co przy dobrze zaprojektowanym systemie nie ma żadnego znaczenia.

Z punktu widzenia klienta korzystającego z usług chmury obliczeniowej problem maszyny (w znaczeniu maszyny fizycznej) również nie istnieje. Instancje OCI migrują się pomiędzy wieloma hostami i jest to proces naturalny. W przypadku awarii któregoś z fizycznych serwerów, dla Ciebie zupełnie nie ma to znaczenia. Twoje usługi działają, tak jakby się nic pod spodem nie wydarzyło. Chmura w ten sposób pomaga nam w byciu ninja.

Co jest obecnie największym i nagminnie pojawiającym się błędem w projektowaniu aplikacji przez deweloperów, z którym musisz sobie radzić?

Rozumiem, że pytanie ma na celu wywołanie flame war w komentarzach (śmiech)? Przecież deweloperzy projektują swoje aplikacje bezbłędnie, a my przygotowujemy zawsze idealne środowiska. Pełna symbioza!

Będąc już bardziej poważnym, to ciężko mówić o typowych błędach w projektowaniu aplikacji. To, na co bardzo często zwracamy uwagę, dotyczy choćby przyzwyczajenia do stosowania NFS, w każdym przypadku gdy mówimy o współdzieleniu zasobów. A przecież jest tyle fajnych rozwiązań, z których można obecnie skorzystać. Mogę Ci zdradzić w tajemnicy, że już niedługo opublikujemy ciekawe plug-iny pozwalające na przechowywanie plików w Oktawave Cloud Storage. Dzięki temu znacznie ułatwiony zostanie proces budowania środowisk HA. Posiadamy również współdzielone dyski, na których można stosować klastrowy system plików, taki jak OCFS2 czy GFS2.

Dość często borykamy się z jeszcze jednym zagadnieniem polegającym na tym, że aplikacje często projektowane są z myślą o dziesiątkach, czy może setkach użytkowników. A co w sytuacji, gdy serwisem zaczynają być zainteresowane tysiące użytkowników? Wtedy zaczynają się problemy. Fajnie byłoby takie rzeczy zakładać od razu na poziomie tworzenia software'u.

Jak często musisz ratować sytuację po tym, jak ktoś inny - podwykonawca, sam klient - popełnił poważny błąd? Jak często musisz gasić pożary, czy zdarza się Wam, że jesteście zrywani z łóżka o np. 4:00 nad ranem?

To, co zdarza się najczęściej, to pożary wynikające ze zbliżającego się deadline'u. Nie musze nawet daleko sięgać w pamięci, bo taki przykład mogę podać nawet z dziś. Środowisko przygotowane od miesiąca, maszyny gotowe, nudzą się. Nagle wrzut appki i panika, bo potrzebna rekonfiguracja usług na 2 czy 3 godziny przed terminem oddania projektu. To jest codzienność (śmiech). Rekord? Odbieram kiedyś telefon (była godzina 11:57) i słyszę: cześć Zbychu, wrzuciliśmy aplikacje i mamy kilka problemów. Standardowo odpowiadam: ok, pomożemy, damy radę, wrzuć ticket. Jednak słyszę w słuchawce: wiesz, ale jest mały problem, bo o 12:00 startujemy. Możesz nie wierzyć, ale udało się temat do 12:00 ogarnąć. Pamiętam też sytuację, gdy na jednym z ekranów, na których mamy odpalony monitoring, wyświetlałem stoper, który odliczał czas do terminu odpalenia projektu i powiem Ci, że minuty strasznie szybko uciekały. Normalka.

W nocy częściej budzi nas monitoring niż klienci czy deweloperzy. A monitoring jest bezlitosny (śmiech). Bardzo często migrujemy usługi właśnie w czasie nocnych dyżurów. Wiadomo, klienci nie mogą sobie pozwolić na przerwy w działaniu usług w czasie dnia, stąd też potrzeba nocnych prac. Standardowe prace staramy się zamykać w godzinach 8:00 - 20:00.

Czego się życzy adminowi?

Skrawka spokojnego snu (śmiech)?

To ninja w ogóle śpią?

To tajemnica.

---

Zdjęcie tytułowe pochodzi z serwisu Shutterstock