Mówimy oczywiście o . Jeśli nie wdawać się w szczegóły, to 30 września i 1 października zorganizujemy konferencję na temat łączenia procesów rozwoju, testowania i eksploatacji, a jeśli już wdawać się w szczegóły, to proszę pod kat.
W podejściu DevOps wszystkie elementy rozwoju technologicznego projektu są ze sobą powiązane, zachodzą równolegle i wzajemnie na siebie wpływają. Szczególne znaczenie ma tutaj tworzenie zautomatyzowanych procesów rozwojowych, które można zmieniać, symulować i testować w czasie rzeczywistym. Dzięki temu możesz błyskawicznie reagować na zmiany na rynku.
Na konferencji chcemy pokazać, jak takie podejście wpływa na rozwój produktu. Jak zapewniona jest niezawodność i możliwość dostosowania systemu do potrzeb klienta. Jak DevOps zmienia strukturę i podejście firmy do organizacji procesu pracy.
za kulisami
Ważne jest dla nas, aby wiedzieć nie tylko, co różne firmy robią w ramach podejścia DevOps, ale także zrozumieć, dlaczego to wszystko się robi. Dlatego do Komitetu Programowego zaprosiliśmy nie tylko ekspertów, ale specjalistów, którzy postrzegają dyskurs DevOps z różnych stanowisk:
- starsi inżynierowie;
- programiści;
- liderzy zespołów;
- Dyrektor Techniczny.
Z jednej strony stwarza to trudności i konflikty podczas omawiania wniosków o sprawozdania. Jeśli inżynier jest zainteresowany analizą poważnej awarii, ważniejsze jest, aby programista wiedział, jak stworzyć oprogramowanie działające w chmurach i infrastrukturze. Ale zgadzając się, tworzymy program, który będzie wartościowy i interesujący dla każdego: od inżynierów po CTO.
Celem naszej konferencji jest nie tylko wybranie najciekawszych raportów, ale pokazanie całościowego obrazu: jak podejście DevOps sprawdza się w praktyce, na jakie prowizje można się natknąć przechodząc na nowe procesy. Jednocześnie budujemy część merytoryczną, schodząc od problemu biznesowego do konkretnych technologii.
Sekcje konferencji pozostaną takie same jak w .
- Platforma infrastrukturalna.
- Infrastruktura jako kod.
- Ciągłe dostawy.
- Informacje zwrotne
- Architektura w DevOps, DevOps dla CTO.
- praktyki SRE.
- Zarządzanie szkoleniami i wiedzą.
- Bezpieczeństwo, DevSecOps.
- Transformacja DevOps.
Call for Papers: jakich raportów oczekujemy
Warunkowo podzieliliśmy potencjalnych odbiorców konferencji na pięć grup: inżynierów, programistów, specjalistów ds. bezpieczeństwa, liderów zespołów oraz CTO. Każda grupa ma swoją motywację do przybycia na konferencję. A jeśli spojrzysz na DevOps z tych pozycji, możesz zrozumieć, jak skupić się na swoim temacie i na czym położyć nacisk.
Dla inżynierów, którzy tworzą platformę infrastrukturalną, ważne jest, aby zrozumieć istniejące trendy, zrozumieć, które technologie są obecnie najbardziej zaawansowane. Będą zainteresowani zdobyciem praktycznych doświadczeń w korzystaniu z tych technologii i wymianą opinii. Inżynier chętnie wysłucha raportu analizującego jakiś poważny wypadek, a my z kolei postaramy się taki raport wybrać i dopracować.
Dla programistów ważne jest, aby zrozumieć takie pojęcie jak aplikacja natywna w chmurze. Czyli jak tworzyć oprogramowanie, aby działało w chmurach i różnych infrastrukturach. Programista musi stale otrzymywać informacje zwrotne na temat oprogramowania. Tutaj chcemy usłyszeć przypadki dotyczące tego, jak firmy budują ten proces, jak monitorować wydajność oprogramowania i jak działa cały proces dostarczania.
Specjaliści od cyberbezpieczeństwa Ważne jest, aby zrozumieć, jak skonfigurować proces bezpieczeństwa, aby nie blokował procesów rozwoju i zmian w firmie. Interesujące będą także tematy dotyczące wymagań jakie DevOps stawia takim specjalistom.
Liderzy zespołów chcą wiedzieć, jak wygląda proces ciągłej dostawy w innych firmach. Jaką drogę przeszły firmy, aby to osiągnąć, jak budowały procesy rozwoju i zapewniania jakości w ramach DevOps. Liderzy zespołów są również zainteresowani rozwiązaniem Cloud native. A także pytania dotyczące interakcji w zespole oraz pomiędzy zespołami programistycznymi i inżynieryjnymi.
dla CTO najważniejsze jest wymyślenie, jak połączyć te wszystkie procesy i dostosować je do potrzeb biznesowych. Dba o to, aby aplikacja była niezawodna zarówno dla biznesu, jak i klienta. I tutaj trzeba zrozumieć, które technologie sprawdzą się przy jakich zadaniach biznesowych, jak zbudować cały proces itp. CTO jest również odpowiedzialny za budżetowanie. Musi na przykład zrozumieć, ile pieniędzy trzeba wydać na przekwalifikowanie specjalistów, aby mogli pracować w DevOps.
Jeśli masz coś do powiedzenia w tych sprawach, nie milcz, . Termin składania ofert upływa 20 sierpnia. Im wcześniej się zarejestrujesz, tym więcej czasu będziesz miał na sfinalizowanie raportu i przygotowanie się do prezentacji. Więc nie zwlekaj.
Cóż, jeśli nie masz potrzeby wypowiadać się publicznie, po prostu i przyjdź 30 września i 1 października, aby porozmawiać z kolegami. Obiecujemy, że będzie ciekawie i inspirująco.
Jak widzimy DevOps
Aby dokładnie zrozumieć, co mamy na myśli mówiąc DevOps, polecam przeczytać (lub ponownie przeczytać) mój raport „" Spacerując po falach rynku, obserwowałem, jak idea DevOps przekształca się w firmach różnej wielkości: od małego startupu po międzynarodowe firmy. Raport zbudowany jest z szeregu pytań, odpowiadając na nie możesz zrozumieć, czy Twoja firma zmierza w stronę DevOps, czy też gdzieś są problemy.
DevOps to złożony system, musi obejmować:
- Produkt cyfrowy.
- Moduły biznesowe rozwijające ten produkt cyfrowy.
- Zespoły produktowe piszące kod.
- Praktyki ciągłego dostarczania.
- Platformy jako usługa.
- Infrastruktura jako usługa.
- Infrastruktura jako kod.
- Oddzielne praktyki utrzymania niezawodności wbudowane w DevOps.
- Praktyka informacji zwrotnej, która opisuje wszystko.
Na końcu raportu znajduje się diagram dający wyobrażenie o systemie DevOps w firmie. Dzięki niemu zobaczysz, które procesy w Twojej firmie zostały już usprawnione, a które dopiero czekają na zbudowanie.
Możesz obejrzeć wideo z raportu .
A teraz będzie bonus: kilka filmów z RIT++ 2019, które poruszają najbardziej ogólne zagadnienia transformacji DevOps.
Infrastruktura firmy jako produkt
Artem Naumenko kieruje zespołem DevOps w Skyeng i dba o rozwój infrastruktury swojej firmy. Opowiadał, jak infrastruktura wpływa na procesy biznesowe w SkyEng: jak wyliczyć dla niej ROI, jakie metryki wybrać do kalkulacji i jak pracować, aby je ulepszyć.
W drodze do mikroserwisów
Firma Nixys zapewnia wsparcie dla obciążonych projektów internetowych i systemów rozproszonych. Jej dyrektor techniczny, Boris Ershov, opowiedział, jak przełożyć na nowoczesną platformę oprogramowanie, którego rozwój rozpoczął się 5 lat temu (lub nawet wcześniej).
Z reguły takie projekty to wyjątkowy świat, w którym znajdują się tak ciemne i starożytne zakątki infrastruktury, że obecni inżynierowie o nich nie wiedzą. A wybrane kiedyś podejścia do architektury i rozwoju są przestarzałe i nie mogą zapewnić biznesowi takiego samego tempa rozwoju i wydawania nowych wersji. Dzięki temu każde wydanie produktu staje się niesamowitą przygodą, w której ciągle coś wypada i to w najbardziej nieoczekiwanym miejscu.
Menedżerowie takich projektów nieuchronnie stają przed koniecznością transformacji wszelkich procesów technologicznych. W swoim raporcie Borys stwierdził:
- jak wybrać odpowiednią architekturę dla projektu i uporządkować infrastrukturę;
- jakich narzędzi użyć i jakie pułapki można napotkać na drodze do transformacji;
- co zrobic nastepnie.
Automatyzacja wydań, czyli jak dostarczać szybko i bezboleśnie
Alexander Korotkov jest wiodącym twórcą systemu CI/CD w CIAN. Mówił o narzędziach automatyzacji, które pozwoliły podnieść jakość i skrócić 5-krotnie czas dostarczania kodu na produkcję. Jednak takich wyników nie udałoby się osiągnąć samą automatyzacją, dlatego Alexander zwrócił uwagę także na zmiany w procesach rozwojowych.
Jak wypadki pomagają Ci się uczyć?
Alexey Kirpichnikov wdraża DevOps i infrastrukturę w SKB Kontur od 5 lat. W ciągu trzech lat w jego firmie wydarzyło się około 1000 fakapów o różnym stopniu epickości. Na przykład 36% z nich było spowodowane wprowadzeniem do produkcji wersji o niskiej jakości, a 14% było spowodowane pracami konserwacyjnymi sprzętu w centrum danych.
Archiwum raportów (sekcji zwłok), które inżynierowie firmy prowadzą od kilku lat z rzędu, pozwala uzyskać tak dokładne informacje o wypadkach. Sekcję zwłok spisuje dyżurny inżynier, który jako pierwszy zareagował na sygnał alarmowy i zaczął wszystko naprawiać. Po co dręczyć inżynierów, którzy po nocach zmagają się z facapami, pisząc raporty? Dane te pozwalają zobaczyć cały obraz i skierować rozwój infrastruktury we właściwym kierunku.
W swoim przemówieniu Aleksiej podzielił się tym, jak napisać naprawdę przydatną sekcję zwłok i jak wdrożyć praktykę sporządzania takich protokołów w dużej firmie. Jeśli lubisz historie o tym, jak ktoś schrzanił, obejrzyj wideo z występu.
Rozumiemy, że Twoja wizja DevOps może nie odpowiadać naszej. Ciekawie będzie dowiedzieć się, jak widzisz transformację DevOps. Podziel się swoimi doświadczeniami i wizją tego tematu w komentarzach.
Jakie raporty przyjęliśmy już do programu?
W tym tygodniu Komitet Programowy przyjął 4 raporty: dotyczące praktyk w zakresie bezpieczeństwa, infrastruktury i SRE.
Być może najbardziej bolesny temat transformacji DevOps: jak zadbać o to, aby ludzie z działu bezpieczeństwa informacji nie zniszczyli już zbudowanych powiązań pomiędzy rozwojem, działaniem i administracją. Niektóre firmy radzą sobie bez działu bezpieczeństwa informacji. Jak w tym przypadku zapewnić bezpieczeństwo informacji? O tym Mona Arkhipova z sudo.su. Z jej relacji dowiadujemy się:
- co należy chronić i przed kim;
- jakie są rutynowe procesy bezpieczeństwa;
- jak krzyżują się procesy IT i bezpieczeństwa informacji;
- czym jest CIS CIS i jak go wdrożyć;
- w jaki sposób i za pomocą jakich wskaźników przeprowadzać regularne kontrole bezpieczeństwa informacji.
Kolejny raport dotyczy rozwoju infrastruktury jako kodu. Zmniejsz ilość ręcznych czynności i nie zamieniaj całego projektu w chaos, czy to możliwe? Na to pytanie Maxim Kostrikin z Ixtens. Jego firma korzysta Terraform do pracy z infrastrukturą AWS. Narzędzie jest wygodne, ale pytanie brzmi, jak uniknąć tworzenia ogromnego bloku kodu podczas jego używania. Utrzymanie takiego dziedzictwa z roku na rok będzie coraz droższe.
Maxim pokaże, jak działają wzorce rozmieszczania kodu, mające na celu uproszczenie automatyzacji i rozwoju.
Inne o infrastrukturze usłyszymy od Władimir Ryabow z Playkey. Tutaj porozmawiamy o platformie infrastrukturalnej i dowiemy się:
- jak zrozumieć, czy przestrzeń magazynowa jest efektywnie wykorzystywana;
- jak kilkuset użytkowników może otrzymać 10 TB treści przy wykorzystaniu jedynie 20 TB przestrzeni dyskowej;
- jak skompresować dane 5-krotnie i udostępnić je użytkownikom w czasie rzeczywistym;
- jak synchronizować dane w locie pomiędzy kilkoma centrami danych;
- jak wyeliminować wpływ użytkowników na siebie nawzajem przy sekwencyjnym korzystaniu z jednej maszyny wirtualnej.
Sekretem tej magii jest technologia ZFS dla FreeBSD i jego świeży widelec ZFS w systemie Linux. Vladimir udostępni przypadki z Playkey.
Matvey Kukuy z Amixr.IO gotowe, z przykładami z życia , Co SRE i jak pomaga budować niezawodne systemy. Amixr.IO przepuszcza przez swój backend incydenty klienckie; dziesiątki dyżurnych zespołów na całym świecie rozpatrzyły już 150 tys. spraw. Na konferencji Matvey podzieli się statystykami i spostrzeżeniami, które jego firma zgromadziła rozwiązując problemy klientów i analizując awarie.
Jeszcze raz namawiam Cię, abyś nie był zachłanny i nie podzielił się swoim doświadczeniem jako samuraj DevOps. Podawać o sprawozdanie, a Państwo i ja będziemy mieli 2,5 miesiąca na przygotowanie doskonałego przemówienia. Jeśli chcesz być słuchaczem, do newslettera z aktualizacjami programu i poważnie zastanów się nad rezerwacją biletów z wyprzedzeniem, bo im bliżej terminów konferencji, tym droższe będą.
Źródło: www.habr.com