Kiedyś w jednej placówce dostarczaliśmy klientowi elektroniczny system zarządzania dokumentami. A potem do innego obiektu. I jeszcze jeden. I na czwartym, i na piątym. Daliśmy się tak ponieść, że dotarliśmy do 10 rozdanych obiektów. Okazało się to potężne... zwłaszcza, gdy przystąpiliśmy do wprowadzania zmian. W ramach dostawy na obwód produkcyjny 5 scenariuszy systemu testowego wymagało docelowo 10 godzin i 6-7 pracowników. Takie koszty zmusiły nas do realizowania dostaw tak rzadko, jak to możliwe. Po trzech latach działania nie mogliśmy tego znieść i postanowiliśmy urozmaicić projekt szczyptą DevOps.
Teraz wszystkie testy trwają 3 godziny i biorą w nich udział 3 osoby: inżynier i dwóch testerów. Ulepszenia są wyraźnie wyrażone w liczbach i prowadzą do zmniejszenia tak lubianego TTM. Z naszego doświadczenia wynika, że z DevOps może skorzystać znacznie więcej klientów, niż tych, którzy w ogóle o tym wiedzą. Dlatego, aby przybliżyć ludziom DevOps, opracowaliśmy prosty konstruktor, o którym szerzej porozmawiamy w tym poście.
Teraz opowiemy bardziej szczegółowo. Jedna z firm energetycznych wdraża system zarządzania dokumentacją techniczną w 10 dużych obiektach. Nie jest łatwo poruszać się po projektach tej skali bez DevOps, ponieważ duży udział pracy ręcznej znacznie opóźnia pracę, a także obniża jakość - każda praca ręczna jest obarczona błędami. Z drugiej strony są projekty, w których jest tylko jedna instalacja, ale wszystko musi działać automatycznie, stale i bezawaryjnie - na przykład te same systemy obiegu dokumentów w dużych organizacjach monolitycznych. W przeciwnym razie ktoś dokona ustawień ręcznie, zapomni o instrukcjach wdrażania - w rezultacie na produkcji ustawienia zostaną utracone i wszystko się zawali.
Zwykle współpracujemy z klientem na podstawie umowy i w tym przypadku nasze interesy nieznacznie się różnią. Klient patrzy na projekt ściśle w ramach budżetu i specyfikacji technicznych. Wyjaśnienie mu korzyści płynących z różnych praktyk DevOps, które nie są ujęte w specyfikacjach technicznych, może być trudne. A jeśli interesuje go szybkie wydanie z wartością dodaną biznesową lub budowanie rurociągu automatyzacji?
Niestety, podczas pracy ze wstępnie zatwierdzonymi kosztami nie zawsze można znaleźć to zainteresowanie. W naszej praktyce zdarzały się przypadki, gdy musieliśmy się zająć opracowaniem wykonawcy pozbawionego skrupułów i nieostrożności. To było okropne: nie było aktualnych kodów źródłowych, baza kodu tego samego systemu była inna w różnych instalacjach, częściowo brakowało dokumentacji, a częściowo była ona fatalnej jakości. Klient oczywiście nie miał kontroli nad kodem źródłowym, montażem, wydaniami itp.
Na razie nie wszyscy wiedzą o DevOps, ale gdy tylko mówimy o jego zaletach, o realnej oszczędności zasobów, oczy wszystkim klientom się rozjaśniają. Dlatego liczba żądań obejmujących DevOps rośnie z biegiem czasu. Tutaj, aby swobodnie rozmawiać z klientami tym samym językiem, musimy szybko połączyć problemy biznesowe i praktyki DevOps, które pomogą zbudować odpowiedni rurociąg deweloperski.
Mamy więc z jednej strony zestaw problemów, z drugiej wiedzę, praktyki i narzędzia DevOps. Dlaczego nie podzielić się tym doświadczeniem ze wszystkimi?
Tworzenie konstruktora DevOps
Agile ma swój własny manifest. ITIL ma swoją własną metodologię. DevOps ma mniej szczęścia – nie nabył jeszcze szablonów i standardów. Chociaż określać dojrzałość przedsiębiorstw na podstawie oceny ich rozwoju i praktyk operacyjnych.
Na szczęście znana firma Gartner w 2014 r i przeanalizowaliśmy kluczowe praktyki DevOps oraz relacje pomiędzy nimi. Na tej podstawie opublikowałem infografikę:
Przyjęliśmy to jako podstawę naszego . Każdy z czterech obszarów posiada zestaw narzędzi – zebraliśmy je w bazę danych, zidentyfikowaliśmy te najpopularniejsze, zidentyfikowaliśmy punkty integracji i odpowiednie mechanizmy optymalizacyjne. W sumie wyszło 36 praktyk i 115 narzędzi, z czego jedna czwarta to oprogramowanie typu open source lub wolne. Następnie porozmawiamy o tym, co osiągnęliśmy w każdym obszarze i jako przykład o tym, jak zostało to wdrożone w projekcie stworzenia zarządzania dokumentacją techniczną, od którego rozpoczęliśmy post.
Procesy
W osławionym projekcie EDMS wdrożono system zarządzania dokumentacją techniczną według tego samego schematu na każdym z 10 obiektów. Instalacja obejmuje 4 serwery: serwer baz danych, serwer aplikacji, indeksowanie pełnotekstowe i zarządzanie treścią. W instalacji działają w ramach jednego węzła i są zlokalizowane w centrum danych na obiektach. Wszystkie obiekty różnią się nieco infrastrukturą, ale nie zakłóca to globalnej interakcji.
Najpierw, zgodnie z praktykami DevOps, zautomatyzowaliśmy infrastrukturę lokalnie, następnie doprowadziliśmy dostawę do obwodu testowego, a następnie do produktu klienta. Każdy proces był opracowywany krok po kroku. Ustawienia środowiska są stałe w systemie kodu źródłowego, biorąc pod uwagę, który pakiet dystrybucyjny jest skompilowany do automatycznej aktualizacji. W przypadku zmian konfiguracyjnych wystarczy, że inżynierowie dokonają odpowiednich zmian w systemie kontroli wersji – a wtedy automatyczna aktualizacja odbędzie się bez problemów.
Dzięki takiemu podejściu proces testowania został znacznie uproszczony. Wcześniej w projekcie byli testerzy, którzy nie robili nic innego, jak tylko ręcznie aktualizowali stoiska. Teraz po prostu przychodzą, sprawdzają, czy wszystko działa i zajmują się bardziej pożytecznymi rzeczami. Każda aktualizacja jest testowana automatycznie – od poziomu powierzchniowego po automatyzację scenariuszy biznesowych. Wyniki są publikowane jako osobne raporty w TestRail.
Kultura
Ciągłe eksperymentowanie najlepiej wyjaśnić na przykładzie projektowania testów. Testowanie systemu, którego jeszcze nie ma, to praca twórcza. Pisząc plan testów, musisz zrozumieć, jak poprawnie testować i jakich gałęzi należy przestrzegać. A także znajdź równowagę między czasem i budżetem, aby określić optymalną liczbę kontroli. Ważne jest, aby wybrać dokładnie niezbędne testy, przemyśleć, w jaki sposób użytkownik będzie współdziałał z systemem, wziąć pod uwagę otoczenie i możliwe czynniki zewnętrzne. Nie da się obejść bez ciągłych eksperymentów.
Teraz o kulturze interakcji. Wcześniej były dwie przeciwstawne strony – inżynierowie i programiści. Twórcy powiedzieli: „Nie obchodzi nas, w jaki sposób zostanie on uruchomiony. Jesteście inżynierami, jesteście mądrzy, zadbajcie o to, żeby to działało bezawaryjnie”. Inżynierowie odpowiedzieli: „Wy, programiści, jesteście zbyt nieostrożni. Bądźmy bardziej ostrożni, a Twoje wydawnictwa będziemy odtwarzać rzadziej. Ponieważ za każdym razem, gdy podajesz nam nieszczelny kod, nie jest dla nas jasne, jak ze sobą współdziałać”.. Jest to problem interakcji kulturowej, który ma inną strukturę z perspektywy DevOps. Tutaj zarówno inżynierowie, jak i programiści stanowią część jednego zespołu, który koncentruje się na ciągle zmieniającym się, ale jednocześnie niezawodnym oprogramowaniu.
W tym samym zespole specjaliści są zdeterminowani, aby sobie pomagać. Jak było wcześniej? Przykładowo, przygotowywano grubą instrukcję wdrożenia, liczącą około 50 stron, inżynier ją przeczytał, czegoś nie zrozumiał, przeklął i o trzeciej nad ranem poprosił programistę o komentarz. Deweloper komentował i przeklinał – ostatecznie nikt nie był zadowolony. Poza tym oczywiście wkradły się pewne błędy, bo nie da się zapamiętać wszystkiego z instrukcji. A teraz inżynier wraz z programistą pisze skrypt do automatycznego wdrażania infrastruktury oprogramowania aplikacyjnego. I rozmawiają ze sobą praktycznie w tym samym języku.
ludzie
Wielkość zespołu zależy od zakresu aktualizacji. Zespół rekrutowany jest w trakcie tworzenia dostawy, w jego skład wchodzą osoby zainteresowane z ogólnego zespołu projektowego. Następnie pisany jest plan aktualizacji z osobami odpowiedzialnymi za każdy etap, a zespół składa raporty z jego postępów. Wszyscy członkowie zespołu są wymienni. W zespole mamy również programistę rezerwowego, ale on prawie nigdy nie musi się łączyć.
Technologia
Na diagramie technologii podświetlonych jest kilka punktów, ale pod nimi kryje się cała masa technologii - można by opublikować całą książkę z ich opisami. Wyróżnimy więc najciekawsze.
Infrastruktura jako kod
Teraz zapewne ta koncepcja nikogo nie zaskoczy, ale wcześniej opisy infrastruktury pozostawiały wiele do życzenia. , środowiska testowe były wyjątkowe, były pielęgnowane i pielęgnowane, zdmuchiwano z nich cząsteczki kurzu.
W dzisiejszych czasach nikt nie boi się eksperymentować. Istnieją podstawowe obrazy maszyn wirtualnych, są gotowe scenariusze wdrażania środowisk. Wszystkie szablony i skrypty przechowywane są w systemie kontroli wersji i są na bieżąco aktualizowane. Wcześniej, gdy konieczne było dostarczenie paczki na stoisko, pojawiała się luka konfiguracyjna. Teraz wystarczy dodać linię do kodu źródłowego.
Oprócz skryptów infrastrukturalnych i potoków, w dokumentacji wykorzystywane jest również podejście Dokumentacja jako kod. Dzięki temu łatwo jest przyłączyć do projektu nowe osoby, wprowadzić je do systemu w oparciu o funkcje opisane np. w planie testów, a także ponownie wykorzystać przypadki testowe.
Ciągłe dostawy i monitorowanie
o DevOps rozmawialiśmy o tym, jak wybieraliśmy narzędzia do wdrażania ciągłego dostarczania i monitorowania. Często nie ma potrzeby przepisywania czegokolwiek - wystarczy skorzystać z napisanych wcześniej skryptów, poprawnie zbudować integrację pomiędzy komponentami i stworzyć wspólną konsolę zarządzającą. A wszystkie procesy można uruchomić za pomocą jednego przycisku lub harmonogramu.
W języku angielskim istnieją różne koncepcje Continuous Delivery i Continuous Deployment. Obydwa można przetłumaczyć jako „dostawa ciągła”, ale tak naprawdę jest między nimi niewielka różnica. W naszym projekcie dotyczącym obiegu dokumentacji technicznej przedsiębiorstwa energetyki rozproszonej stosuje się raczej Dostawę – gdy instalacja do produkcji odbywa się na zlecenie. W przypadku wdrożenia instalacja odbywa się automatycznie. Ciągłe dostarczanie w tym projekcie stało się ogólnie rzecz biorąc centralna część DevOps.
Ogólnie rzecz biorąc, zbierając pewne parametry, można jasno zrozumieć, dlaczego praktyki DevOps są przydatne. I przekaż to kierownictwu, które naprawdę kocha liczby. Całkowita liczba uruchomień, czas wykonania etapów skryptu, udział udanych uruchomień – to wszystko bezpośrednio wpływa na ulubiony przez wszystkich czas wprowadzenia produktu na rynek, czyli czas od zatwierdzenia do systemu kontroli wersji do wydania wersji na platformie środowisko produkcyjne. Dzięki wdrożeniu niezbędnych narzędzi inżynierowie otrzymują pocztą cenne wskaźniki, a kierownik projektu widzi je na dashboardzie. W ten sposób możesz od razu ocenić korzyści płynące z nowych narzędzi. Możesz także wypróbować je na swojej infrastrukturze, korzystając z projektanta DevOps.
Kto będzie potrzebował naszego ?
Nie udawajmy: na początek stał się dla nas przydatny. Jak już powiedzieliśmy, z klientem trzeba rozmawiać tym samym językiem, a przy pomocy projektanta DevOps możemy szybko nakreślić podstawy takiej rozmowy. Specjaliści biznesowi będą mogli sami ocenić, czego potrzebują i dzięki temu szybciej się rozwijać. Staraliśmy się, aby projektant był jak najbardziej szczegółowy, dodając szereg opisów, aby każdy użytkownik zrozumiał, co wybiera.
Format projektanta pozwala uwzględnić istniejący rozwój firmy w zakresie procesów budowlanych i automatyzacji. Nie ma potrzeby burzenia wszystkiego i odbudowywania, wystarczy wybrać rozwiązania, które dobrze integrują się z istniejącymi procesami i mogą po prostu wypełnić luki.
Być może Twój rozwój wszedł już na wyższy poziom i nasze narzędzie będzie wydawać się zbyt „kapitańskie”. Uważamy jednak, że jest to przydatne dla nas samych i mamy nadzieję, że będzie przydatne dla niektórych czytelników. Przypominamy do projektanta - jeśli tak, schemat otrzymasz od razu po wprowadzeniu danych początkowych. Będziemy wdzięczni za Twoją opinię i uzupełnienia.
Źródło: www.habr.com