Tworzenie i eksploatacja oprogramowania

menu icon

Tworzenie i eksploatacja oprogramowania

Tworzenie i eksploatacja oprogramowania przyspiesza dostarczanie oprogramowania wyższej jakości poprzez łączenie i automatyzację pracy zespołów ds. programowania i operacji IT.

Na czym polega tworzenie i eksploatacja oprogramowania?

Z definicji metodyka DevOps nakreśla proces tworzenia oprogramowania i zmianę kultury organizacyjnej, co przyspiesza dostarczanie oprogramowania wyższej jakości przez automatyzację i integrację działań zespołów ds. programowania i operacji IT — dwóch grup, które tradycyjnie pracowały oddzielnie.

W praktyce najlepsze kultury oraz procesy tworzenia i eksploatacji oprogramowania wykraczają poza programowanie i operacje, uwzględniają wkład wszystkich interesariuszy aplikacji — w tym działów inżynierii platformy i infrastruktury, bezpieczeństwa, zgodności, nadzoru, zarządzania ryzykiem i biznesowego oraz użytkowników końcowych i klientów — w cykl życia tworzenia oprogramowania.

Tworzenie i eksploatacja oprogramowania reprezentuje obecny stan trwającej od ponad 20 lat ewolucji cykli dostarczania oprogramowania — od ogromnych, obejmujących całą aplikację wydań kodu co kilka miesięcy lub nawet lat po iteracyjne, mniejsze aktualizacje funkcji wydawane codziennie lub kilka razy dziennie.

Ostatecznie w tworzeniu i eksploatacji oprogramowania chodzi o spełnianie coraz większych potrzeb użytkowników oprogramowania dotyczących częstego dodawania innowacyjnych nowych funkcji, a także nieprzerwanej dostępności i wysokiej wydajności.

Jak dotarliśmy do tworzenia i eksploatacji oprogramowania

Przed rokiem 2000 tworzenie i aktualizowanie większości oprogramowania odbywało się przy użyciu metodologii kaskadowej, liniowego podejścia do dużych projektów programistycznych. Zespoły ds. tworzenia oprogramowania spędzały całe miesiące na opracowywaniu dużych ilości nowego kodu, który miał wpływ na całą aplikację lub jej większość. Ponieważ zmiany były tak obszerne, kilka kolejnych miesięcy trzeba było poświęcić na integrowanie tego nowego kodu z podstawą kodu.

Następnie zespoły ds. zapewniania jakości, bezpieczeństwa i operacji testowały kod przez kolejne miesiące. W rezultacie między publikacją kolejnych wersji oprogramowania upływało kilka miesięcy lub nawet lat, a między wersjami pojawiały się także duże poprawki. Takie podejście do dostarczania funkcji często charakteryzowało się złożonymi i ryzykownymi planami wdrożenia, trudnymi do zaplanowania powiązaniami z nadrzędnymi i podrzędnymi systemami oraz nadzieją, że wymagania biznesowe nie zmieniły się znacząco w ciągu wielu miesięcy prowadzących do opublikowania ostatecznej wersji.

Aby przyspieszyć pracę i poprawić jakość, zespoły programistyczne zaczęły wdrażać zwinne metodologie tworzenia oprogramowania, które są iteracyjne, a nie liniowe i koncentrują się na wprowadzaniu mniejszych, ale częstszych aktualizacji podstawy kodu aplikacji. Główne metodologie tego typu to integracja ciągła i dostarczanie ciągłe (CI/CD). W metodologii CI/CD mniejsze porcje nowego kodu są scalane z podstawą kodu co jeden lub dwa tygodnie, a następnie automatycznie integrowane, testowane i przygotowywane do wdrożenia w środowisku produkcyjnym. Metodologia zwinna umożliwiła przejście od publikowania jednej, dużej aktualizacji do wydawania serii mniejszych, co spowodowało także rozdzielenie czynników ryzyka.

Im efektywniej ta metodologia przyspieszała tworzenie i dostarczanie oprogramowania, tym bardziej pokazywała, że nadal odseparowane operacje IT — udostępnianie systemu, konfiguracja, testy odbiorcze, zarządzanie, monitorowanie — będą następnym wąskim gardłem w cyklu życia dostarczania oprogramowania.

Procedury tworzenia i eksploatacji oprogramowania rozwinęły się dzięki metodykom zwinnym. Spowodowały one dodanie nowych procesów i narzędzi rozszerzających ciągłe iterowanie i automatyzację potoków CI/CD na pozostałą część cyklu życia dostarczania oprogramowania. Ponadto umożliwiły ścisłą współpracę między zespołami programistycznymi i operacyjnymi na każdym etapie procesu.

Jak działa tworzenie i eksploatacja oprogramowania: Cykl życia tworzenia i eksploatacji oprogramowania

Wykres przedstawiający ścieżkę cyklu życia tworzenia i eksploatacji oprogramowania

Ilustracja 1: Cykl życia tworzenia i eksploatacji oprogramowania

Cykl życia tworzenia i eksploatacji oprogramowania (czasami nazywany potokiem dostarczania ciągłego, gdy jest przedstawiany w sposób liniowy) jest serią iteracyjnych, zautomatyzowanych procesów programistycznych (przepływów pracy) wykonywanych w ramach większego, zautomatyzowanego i iteracyjnego cyklu tworzenia aplikacji przeznaczonego do optymalizacji szybkiego dostarczania oprogramowania wysokiej jakości. Ilość i nazwy przepływów pracy mogą być różne, ale zwykle wyróżnia się sześć następujących:

  • Planowanie (tworzenie koncepcji). W tym przepływie pracy zespoły opracowują nowe funkcje dla następnej wersji, opierając się na opiniach użytkowników końcowych o ustalonym priorytecie i analizach wdrożeń, a także informacjach od wszystkich wewnętrznych interesariuszy. Celem etapu planowania jest zmaksymalizowanie wartości biznesowej produktu przez utworzenie rejestru funkcji, które po dostarczeniu zapewnią żądany, wartościowy wynik.
  • Tworzenie. To krok programowania, w którym programiści testują, kodują oraz budują nowe i rozszerzone funkcje w oparciu o opisy sytuacji użytkowników i elementy pracy znajdujące się w rejestrze produktu. Często stosowane są praktyki takie jak projektowanie oparte na testach, programowanie w parach i przeglądy kodu przez współpracowników. Programiści często wykonują „wewnętrzną pętlę” pisania i testowania kodu na swoich lokalnych stacjach roboczych zanim prześlą go dalej w potoku dostarczania ciągłego.
  • Integracja (budowanie lub integracja ciągła i dostarczanie ciągłe (CI/CD)). Jak wspomniano wcześniej, w tym przepływie pracy nowy kod jest integrowany z istniejącą podstawą kodu, a następnie testowany i pakowany w wykonywalny kod. Typowe działania automatyzacji obejmują scalanie zmian kodu z wersją główną, pobieranie tego kodu z repozytorium kodu źródłowego oraz automatyzację kompilowania, testowania jednostkowego i pakowania w kod wykonywalny. Sprawdzoną procedurą jest przechowywanie danych wyjściowych fazy integracji ciągłej w repozytorium binarnym na potrzeby następnej fazy.
  • Wdrażanie (zwykle nazywane wdrażaniem ciągłym). Na tym etapie kompilacja wyjściowa (z integracji) jest wdrażana w środowisku wykonawczym — zwykle jest to środowisko programistyczne, w którym wykonywane są testy środowiska wykonawczego pod kątem jakości, zgodności i bezpieczeństwa. Jeśli zostaną znalezione błędy lub usterki, programiści mają szansę na wychwycenie i usunięcie problemów zanim kod trafi do użytkowników końcowych. Zwykle istnieją środowiska programistyczne, testowe i produkcyjne, a każde kolejne środowisko wymaga coraz ściślejszej kontroli jakości. Dobrą praktyką wdrażania w środowisku produkcyjnym jest wdrożenie najpierw dla podzbioru użytkowników końcowych, a następnie, po potwierdzeniu stabilności, dla wszystkich użytkowników.
  • Operacje. Dostarczanie funkcji do środowiska produkcyjnego nazywa się 1. dniem, natomiast gdy funkcje działają w środowisku produkcyjnym, wykonywane są operacje 2. dnia. Monitorowanie wydajności, zachowania i dostępności funkcji zapewnia, że stanowią one wartość dodaną dla użytkowników końcowych. Operacje zapewniają płynne działanie funkcji oraz brak przerw w świadczeniu usługi przez upewnienie się, że sieć, pamięć masowa, platforma, zasoby obliczeniowe i zabezpieczenia działają poprawnie. Jeśli wystąpi jakiś problem, w ramach operacji identyfikowane są incydenty, powiadamiany jest odpowiedni personel, określane są problemy i zastosowywane poprawki.
  • Nauka (czasem nazywana opiniowaniem ciągłym). Jest to zbieranie opinii od użytkowników końcowych i klientów na temat możliwości, funkcjonalności, wydajności i wartości biznesowej. Te opinie są następnie wykorzystywane podczas planowania ulepszeń i funkcji w następnej wersji. Obejmuje to również wszelkie wnioski i pozycje rejestru produktu z działań operacyjnych, które mogą pozwolić programistom na proaktywne unikanie wszelkich przeszłych incydentów, które mogłyby wystąpić ponownie w przyszłości. To jest właśnie punkt, w którym następuje powrót do fazy planowania i możemy mówić o ulepszaniu ciągłym.

Między tymi przepływami pracy występują trzy inne ważne ciągłe przepływy pracy:

Testowanie ciągłe: klasyczne cykle życia tworzenia i eksploatacji oprogramowania obejmują odrębną fazę testów, która występuje między integracją a wdrażaniem. Jednak rozwój procedur tworzenia i eksploatacji oprogramowania doprowadził do tego, że część testowania można przeprowadzać w ramach planowania (programowanie sterowane zachowaniem), tworzenia (testy jednostkowe, testy kontraktowe), integracji (skany kodu statycznego, skany CVE, linting), wdrażania (testy dymne, testy penetracyjne, testy konfiguracji), operacji (testy chaotyczne, testy zgodności) i nauki (testy A/B). Testowanie to dający wiele możliwości sposób na identyfikację ryzyka i słabych punktów zabezpieczeń. Dzięki niemu dział IT może akceptować, ograniczać lub eliminować ryzyko.

Bezpieczeństwo: metodologie kaskadowe i implementacje w ramach metodyk zwinnych dodają przepływy pracy związane z bezpieczeństwem po dostarczeniu lub wdrożeniu, natomiast metodyka DevOps stara się uwzględniać bezpieczeństwo od samego początku (planowanie) — gdy problemy z bezpieczeństwem można rozwiązać najłatwiej i najmniejszym kosztem — oraz nieprzerwanie przez całą resztę cyklu tworzenia oprogramowania. To podejście do bezpieczeństwa zakłada testowanie na wcześniejszych etapach (łatwiej to zrozumieć po spojrzeniu na ilustrację 1). W przypadku niektórych organizacji testowanie na wcześniejszych etapach nie było tak skuteczne, jak w przypadku innych, co doprowadziło do powstania metodyki DevSecOps (patrz poniżej).

Zgodność. Zgodnością z przepisami (nadzór i ryzyko) również najlepiej zająć się wcześnie i w całym cyklu tworzenia aplikacji. Firmy z branż podlegających ścisłym regulacjom prawnym często muszą zapewnić pewien poziom obserwowalności, możliwości śledzenia i dostępu w związku ze sposobem dostarczania funkcji i zarządzania nimi w wykonawczym środowisku operacyjnym. To wymaga planowania, programowania, testowania i egzekwowania strategii w potoku dostarczania ciągłego i w środowisku wykonawczym. Możliwości kontroli środków zapewniania zgodności z przepisami są niezwykle ważne, aby można było udowodnić zgodność audytorom z innych firm.

Kultura tworzenia i eksploatacji oprogramowania

Ogólnie uznaje się, że metody tworzenia i eksploatacji oprogramowania nie będą działać bez zaangażowania w kulturę tworzenia i eksploatacji oprogramowania, którą można podsumować jako inne organizacyjnie i technicznie podejście do tworzenia oprogramowania.

Na poziomie organizacyjnym tworzenie i eksploatacja oprogramowania wymaga ciągłej komunikacji, współpracy i współodpowiedzialności wszystkich interesariuszy zaangażowanych w dostarczanie oprogramowania — na pewno są to zespoły ds. programowania i operacji IT, ale także zespoły ds. bezpieczeństwa, zachowania zgodności, nadzoru i ryzyka oraz zespoły biznesowe — w celu szybkiego i ciągłego wprowadzania innowacji oraz zapewniania wysokiej jakości oprogramowania od samego początku.

W większości przypadków najlepszym sposobem na osiągnięcie tego celu jest reorganizacja i łączenie personelu w wielozadaniowe, autonomiczne zespoły tworzenia i eksploatacji oprogramowania, które mogą pracować nad projektami od początku do końca — od planowania po zbieranie opinii — bez przekazywania ich innym zespołom ani czekania na zatwierdzenie przez inne zespoły. W kontekście programowania opartego na metodykach zwinnych współodpowiedzialność i współpraca to fundamenty wspólnej koncentracji na produkcie, dzięki której można uzyskać wartościowy wynik.

Na poziomie technicznym tworzenie i eksploatacja oprogramowania wymaga zaangażowania w automatyzację, dzięki której projekty przechodzą między poszczególnymi etapami przepływów pracy oraz między całymi przepływami pracy, a także w zbieranie opinii i pomiary umożliwiające zespołom ciągłe przyspieszanie cykli oraz zwiększanie jakości i wydajności oprogramowania.

Narzędzia do tworzenia i eksploatacji oprogramowania: Budowanie łańcucha narzędzi do tworzenia i eksploatacji oprogramowania

Wymagania związane z procedurami i kulturą DevOps powodują, że pożądane są narzędzia wspierające asynchroniczną współpracę, które bezproblemowo integrują przepływy pracy tworzenia i eksploatacji oprogramowania oraz maksymalnie automatyzują cały cykl życia tworzenia i eksploatacji oprogramowania. Kategorie narzędzi tworzenia i eksploatacji oprogramowania:

  • Narzędzia do zarządzania projektami — narzędzia umożliwiające zespołom budowanie rejestru historii użytkowników (wymagań), które tworzą projekty kodowania, dzielą je na mniejsze zadania i śledzą zadania do ukończenia. Wiele z nich wspiera zwinne metodyki zarządzania projektami, takie jak Scrum, Lean i Kanban, które programiści stosują w ramach tworzenia i eksploatacji oprogramowania. Popularne rozwiązania Open Source to GitHub Issues i Jira.
  • Grupowe repozytoria kodu źródłowego — środowiska kodowania z kontrolą wersji, które pozwalają wielu programistom na pracę nad tą samą podstawą kodu. Repozytoria kodu powinny się integrować z narzędziami CI/CD, narzędziami do testowania i narzędziami bezpieczeństwa, aby kod mógł automatycznie przechodzić do następnego kroku po jego zatwierdzeniu w repozytorium. Repozytoria kodu Open Source to m.in. GitHub i GitLab.
  • Potoki CI/CD — narzędzia automatyzujące pobieranie, budowanie, testowanie i wdrażanie kodu. Jenkins to najpopularniejsze narzędzie Open Source z tej kategorii. Wiele alternatyw, które wcześniej były dostępne jako projekty Open Source, np. CircleCI, są teraz dostępne tylko w wersjach komercyjnych. Jeśli chodzi o narzędzia do wdrażania ciągłego (CD), Spinnaker stoi między warstwami aplikacji i infrastruktury jako kodu. ArgoCD to inny popularny wybór Open Source dla procesów CI/CD stworzonych z myślą o platformie Kubernetes.
  • Struktury automatyzacji testów — obejmują narzędzia programowe, biblioteki i sprawdzone procedury dotyczące automatyzacji testów jednostkowych, kontraktowych, funkcjonalnych, wydajnościowych, użyteczności, penetracyjnych i bezpieczeństwa. Najlepsze z tych narzędzi obsługują wiele języków, a niektóre wykorzystują sztuczną inteligencję, aby automatycznie rekonfigurować testy po zmianach kodu. Dostępnych jest bardzo wiele struktur i narzędzi do testowania. Popularne struktury Open Source do automatyzacji testów to m.in. Selenium, Appium, Katalon, Robot Framework i Serenity (wcześniej znana pod nazwą Thucydides).
  • Narzędzia do zarządzania konfiguracją (infrastruktura jako kod) — umożliwiają inżynierom DevOps konfigurowanie i udostępnianie w pełni udokumentowanej infrastruktury z pełną kontrolą wersji przez wykonanie skryptu. Opcje Open Source to m.in. Ansible (Red Hat), Chef, Puppet i Terraform. Platforma Kubernetes spełnia tę samą funkcję w przypadku aplikacji kontenerowych (patrz poniższa sekcja „Tworzenie i eksploatacja oprogramowania oraz tworzenie z myślą o chmurze”).
  • Narzędzia do monitorowania — pomagają zespołom DevOps w identyfikowaniu problemów z systemem i ich rozwiązywaniu. Ponadto zbierają i analizują dane w czasie rzeczywistym, aby pokazać, jak zmiany kodu wpływają na wydajność aplikacji. Narzędzia Open Source do monitorowania to m.in. Datadog, Nagios, Prometheus i Splunk.
  • Narzędzia do opiniowania ciągłego — narzędzia, które zbierają opinie użytkowników za pomocą mapy termicznej (przez rejestrowanie działań użytkowników na ekranie), ankiet lub samoobsługowego zgłaszania problemów.

Tworzenie i eksploatacja oprogramowania oraz tworzenie z myślą o chmurze

Tworzenie z myślą o chmurze jest podejściem do tworzenia aplikacji, które wykorzystuje podstawowe technologie przetwarzania w chmurze. Celem tworzenia z myślą o chmurze jest umożliwienie spójnego i optymalnego tworzenia, wdrażania oraz zapewniania wydajności aplikacji, a także zarządzania nimi w środowiskach publicznych, prywatnych i wielochmurowych.

Obecnie aplikacje stworzone z myślą o chmurze mają zazwyczaj następujące cechy:

  • Zbudowane przy użyciu mikrousług — luźno powiązanych komponentów, które można wdrażać niezależnie oraz które mają własny, autonomiczny stos i komunikują się ze sobą za pośrednictwem interfejsów API REST, strumieniowego przesyłania zdarzeń lub brokerów komunikatów.
  • Wdrażane w kontenerach — wykonywalnych jednostkach kodu, które zawierają wszystkie zależności kodu, środowisk wykonawczych i systemu operacyjnego wymagane do uruchomienia aplikacji. (W przypadku większości organizacji „kontenery” są synonimem kontenerów Docker, ale istnieją też inne typy kontenerów).
  • Eksploatowane (na dużą skalę) przy użyciu Kubernetes, platformy Open Source do harmonizacji kontenerów umożliwiającej tworzenie harmonogramów oraz automatyzowanie wdrażania i skalowania aplikacji kontenerowych oraz zarządzania nimi.

Pod wieloma względami tworzenie z myślą o chmurze oraz tworzenie i eksploatacja oprogramowania są dla siebie stworzone.

Na przykład tworzenie i aktualizowanie mikrousług — to znaczy iteracyjne dostarczanie małych jednostek kodu do małej podstawy kodu — świetnie wpisuje się w szybkie cykle wydawania i zarządzania w ramach DevOps. Dodatkowo obsłużenie złożoności architektury mikrousług bez metodyki DevOps byłoby trudne. Dane uzyskane w wyniku niedawnej ankiety IBM przeprowadzonej wśród programistów i dyrektorów IT pokazują, że 78% obecnych użytkowników mikrousług prawdopodobnie zwiększy czas, pieniądze i nakład pracy zainwestowane w tę architekturę, a 56% podmiotów, które nie używają mikrousług, prawdopodobnie wdroży je w ciągu kolejnych dwóch lat. Za pomocą poniższego interaktywnego narzędzia można poznać więcej korzyści i wyzwań związanych z mikrousługami:

(Źródło: „Microservices in the enterprise 2021: Real benefits, worth the challenges”).

Dzięki spakowaniu i trwałemu ustaleniu wszystkich zależności systemu operacyjnego kontenery umożliwiają stosowanie szybkich cykli CI/CD i wdrażania, ponieważ cała integracja, testowanie i wdrażanie odbywa się w tym samym środowisku. W ramach harmonizacji na platformie Kubernetes dla aplikacji kontenerowych są wykonywane te same zadania konfiguracji ciągłej, co w rozwiązaniach Ansible, Puppet i Chef w przypadku aplikacji niekontenerowych.

Większość czołowych dostawców usług przetwarzania w chmurze — w tym AWS, Google, Microsoft Azure oraz IBM Cloud — oferuje zarządzane rozwiązanie do obsługi potoku tworzenia i eksploatacji oprogramowania.

Czym jest DevSecOps?

DevSecOps to tworzenie i eksploatacja oprogramowania wzbogacone o ciągłą integrację i automatyzację zabezpieczeń w całym cyklu życia tworzenia i eksploatacji oprogramowania — od początku do końca, od planowania przez opiniowanie i z powrotem do planowania.

Innymi słowy tworzenie, zabezpieczanie i eksploatacja oprogramowania jest tym, czym tworzenie i eksploatacja oprogramowania miała być od samego początku. Jednak dwoma z wczesnych znaczących (i, do pewnego czasu, niemożliwych do pokonania) wyzwań związanych z wdrażaniem procedur DevOps było zintegrowanie wiedzy specjalistycznej z dziedziny bezpieczeństwa w wielozadaniowych zespołach (problem kulturowy) oraz implementacja automatyzacji bezpieczeństwa w cyklu życia tworzenia i eksploatacji oprogramowania (problem techniczny). Bezpieczeństwo było postrzegane jako zespół, który jest na „Nie”, oraz jako kosztowne wąskie gardło w wielu procedurach tworzenia i eksploatacji oprogramowania.

Metodyka DevSecOps pojawiła się jako próba zintegrowania i zautomatyzowania bezpieczeństwa zgodnie z pierwotnymi założeniami. W metodyce DevSecOps bezpieczeństwo jest równoprawne z tworzeniem i eksploatacją. Wprowadza bezpieczeństwo do procesu tworzenia oprogramowania koncentrującego się na produkcie.

Obejrzyj film pt. „Czym to jest tworzenie, zabezpieczanie i eksploatacja oprogramowania?”, aby dowiedzieć się więcej o zasadach, korzyściach i przykładach użycia DevSecOps:

Tworzenie i eksploatacja oprogramowania oraz inżynieria niezawodności serwisu (SRE)

Inżynieria niezawodności serwisu (SRE) wykorzystuje techniki inżynierii oprogramowania do automatyzacji zadań związanych z operacjami IT — np. zarządzaniem systemem produkcyjnym, zarządzaniem zmianami, reagowaniem na incydenty, a nawet reagowaniem na awarie — które w innym przypadku byłyby wykonywane ręcznie przez administratorów systemów. Podejście SRE stara się przekształcić klasycznego administratora systemu w inżyniera.

Ostateczny cel podejścia SRE jest podobny do celu tworzenia i eksploatacji oprogramowania, ale jest bardziej konkretny: SRE ma na celu zrównoważenie dążenia organizacji do szybkiego rozwoju aplikacji z potrzebą zapewnienia poziomów wydajności i dostępności określonych w umowach dotyczących poziomu usług (SLA) zawartych z klientami i użytkownikami końcowymi.

Inżynierowie ds. niezawodności serwisu osiągają tę równowagę przez określenie akceptowalnego poziomu ryzyka operacyjnego powodowanego przez aplikacje — nazywanego budżetem błędów — i zautomatyzowanie operacji pod kątem osiągnięcia tego poziomu.

W ramach wielozadaniowego zespołu DevOps inżynier ds. niezawodności serwisu stanowi pomost między tworzeniem i eksploatacją, zapewniając metryki i automatyzacje potrzebne zespołowi do jak najszybszego przeprowadzania zmian kodu i nowych funkcji przez potok tworzenia i eksploatacji oprogramowania bez naruszania warunków umów SLA organizacji.

Dowiedz się więcej o SRE

Tworzenie i eksploatacja oprogramowania a IBM Cloud

Tworzenie i eksploatacja oprogramowania wymaga współpracy między interesariuszami z dziedziny biznesu, tworzenia i eksploatacji, aby szybko dostarczać i uruchamiać niezawodne oprogramowanie. Organizacje, które używają narzędzi oraz procedur DevOps, jednocześnie przekształcając swoją kulturę, budują mocny fundament dla transformacji cyfrowej i modernizacji swoich aplikacji, który będzie konieczny w miarę zwiększania się potrzeb automatyzacji operacji biznesowych i IT.

Przejście w kierunku większej automatyzacji powinno rozpocząć się od małych, udanych projektów, które następnie można skalować i optymalizować pod kątem innych procesów i w innych częściach organizacji.

Współpracując z IBM, uzyskasz dostęp do opartych na sztucznej inteligencji funkcji automatyzacji, w tym gotowych przepływów pracy, dzięki którym zapewnisz inteligentne usługi IT. W konsekwencji pozwoli to zespołom skoncentrować się na najważniejszych problemach IT i szybszym wprowadzaniu innowacji.

Wykonaj kolejny krok:

Załóż konto IBM Cloud już dzisiaj.

IBM Cloud Pak for Watson AIOps wykorzystuje uczenie maszynowe i rozumienie języka naturalnego do korelowania ustrukturyzowanych i nieustrukturyzowanych danych w całym łańcuchu narzędzi operacyjnych w czasie rzeczywistym, aby ujawnić ukryte informacje i pomóc szybciej identyfikować podstawowe przyczyny problemów. Eliminując potrzebę korzystania z wielu paneli kontrolnych, Watson AIOps przekazuje analizy i zalecenia bezpośrednio do przepływów pracy zespołu, aby przyspieszyć przetwarzanie incydentów.

Informacje o autorze

Andrea C. Crawford jest wyróżnionym inżynierem w IBM i dysponuje wiedzą specjalistyczną z dziedziny klasycznego oraz nowoczesnego tworzenia i eksploatacji oprogramowania. Pasjonuje się pomaganiem klientom w transformowaniu dostarczania aplikacji dzięki modernizacji narzędzi, procesów i osób. Andrea lubi poznawać taktyczne, odrębne dziedziny takie jak ogrodnictwo czy jazda na motocyklu.

https://twitter.com/acmthinks (odsyłacz prowadzi poza serwis IBM)

https://medium.com/@acmThinks (odsyłacz prowadzi poza serwis IBM)