Ujemna prędkość: jak podnieść granicę złożoności
Jednym z najczęstszych celów organizacji inżynieryjnych jest szybkie dostarczanie wysokiej jakości oprogramowania.
Przyjrzyj się wizji dyrektora ds. informatycznych i dyrektora ds. technicznych w swojej firmie i posłuchaj, co mówią te osoby. Prawdopodobnie dążą do osiągnięcia jakiejś permutacji tego celu. Choć jest to często stawiany cel, spektrum jego realizacji jest szerokie — od zespołów, które osiągają znakomite rezultaty, po zespoły które utknęły w odmętach dostarczania oprogramowania. Niektóre zespoły konsekwentnie wprowadzają do produkcji nowy kod, napotykając nieliczne incydenty i wywierając niewielki negatywny wpływ na klientów, podczas gdy inne mają problemy z wydaniami kwartalnymi.
Jednym z najczęstszych celów organizacji inżynieryjnych jest szybkie dostarczanie wysokiej jakości oprogramowania.
Przyjrzyj się wizji dyrektora ds. informatycznych i dyrektora ds. technicznych w swojej firmie i posłuchaj, co mówią te osoby. Prawdopodobnie dążą do osiągnięcia jakiejś permutacji tego celu. Choć jest to często stawiany cel, spektrum jego realizacji jest szerokie — od zespołów, które osiągają znakomite rezultaty, po zespoły które utknęły w odmętach dostarczania oprogramowania. Niektóre zespoły konsekwentnie wprowadzają do produkcji nowy kod, napotykając nieliczne incydenty i wywierając niewielki negatywny wpływ na klientów, podczas gdy inne mają problemy z wydaniami kwartalnymi.
Co powoduje tę rozbieżność w wydajności?
W przypadku dostarczania oprogramowania złożoność to różnica między szybkim dostarczaniem wysokiej jakości oprogramowania a… brakiem dostarczania. Jest to różnica między biciem co tydzień w dzwon zwycięstwa po udanym wydaniu a frustracją niezaangażowanego zespołu, który po miesiącach pracy nad najnowszą wersją uzyskuje efekt w postaci sześciu nowych błędów i przywracania.
Porównajmy prędkość i jakość dostarczania nowych produktów i funkcji przez startupy z tymi samymi parametrami w dużej organizacji o ugruntowanej pozycji. Przykładowo w ciągu ostatniej dekady w branży finansowej startupy fintech spowodowały zmniejszenie udziału rynkowego dużych banków o ugruntowanej pozycji. Duże banki często powołują się na nieuczciwą przewagę startupów fintech, które funkcjonują pod mniejszym nadzorem regulacyjnym i nie muszą utrzymywać starszych, monolitycznych zestawów aplikacji. Mniejsze zespoły oznaczają większą zwinność i możliwość dostosowywania się w zależności od potrzeb klienta. Zasadniczo fintechy nie są tak złożone jak uznane banki, co pozwala im działać szybciej przy mniejszym ryzyku. Chociaż złożoność może spowalniać zespoły programistyczne, nie zawsze jest zła.
materiały pokrewne
Ograniczenie nadmiernej rozbudowy oprogramowania
POZNAJ ROZWIĄZANIE
Zarządzanie komponentami za pomocą rozwiązania Compass
Złożoność dostarczania oprogramowania
Złożoność może być dobra: rozwiązywanie zawiłych problemów jest niezwykle satysfakcjonujące. Motywuje zespoły, aby sprostać wyzwaniom, rozwiązywać trudne problemy i dokonywać przełomów. I odwrotnie — od pewnego momentu złożoność nie polega już na rozwiązywaniu trudnych problemów i wywiera negatywny wpływ na zespoły programistyczne.
Złożoność organizacyjna odgrywa zasadniczą rolę w ograniczaniu efektywności zespołów programistycznych. Słownikowo złożoność jest definiowana jako stan posiadania wielu różnych części połączonych lub powiązanych ze sobą w skomplikowany sposób. W praktyce złożoność organizacyjna to agregat informacji, zależności, zmian, innych zespołów, narzędzi i wniosków, po których zespoły oprogramowania muszą poruszać się podczas wchodzenia w interakcje z pozostałą częścią organizacji.
Wyższy poziom złożoności organizacyjnej naturalnie utrudnia szybkie dostarczanie wysokiej jakości oprogramowania, ponieważ zespoły spędzają więcej czasu na poruszaniu się po organizacji niż na rozwiązywaniu zawiłych problemów. Rosnące organizacje szybko przekonują się, że zespoły programistyczne osiągają granicę złożoności — stopień złożoności, którego przekroczenie negatywnie wpływa na działanie zespołu, zadowolenie z pracy oraz na jakość oprogramowania i prędkość jego dostarczania. Może się zatem wydawać logiczne, że zmniejszenie złożoności organizacyjnej pozwala zespołom skupić się na rozwiązywaniu zawiłych problemów, dostarczaniu oprogramowania szybciej i w wyższej jakości. Zastanówmy się, dlaczego niekoniecznie tak jest.
Jak sprawdzić, czy granica złożoności jest blisko
Osiągnięcie granicy złożoności wydaje się nieuniknione, ale istnieją oznaki pozwalające stwierdzić, że zespół zbliża się do niej. Najpierw jednak muszę zaznaczyć, że nie ma bezwzględnego wskaźnika, który pokazuje, ile dzieli Cię od granicy złożoności, jednak opisane poniżej oznaki mogą pomóc Ci w ustaleniu, ile zostało Ci do tej.
Najbardziej oczywistą oznaką, że zespół osiągnął granicę złożoności, jest to, że spędza więcej czasu na poruszaniu się po złożoności organizacyjnej niż na rozwiązywaniu zawiłych problemów, na których powinien się skupić. Przyjrzenie się tendencjom czasu wdrażania zmian (prędkość) i wskaźników błędnych zmian (jakość) wg DORA pozwala zorientować się, czy zespoły zwalniają, czy przyspieszają. Chociaż na te wskaźniki wpływają też inne elementy, są dobrą oznaką efektywności zespołu.
Zadowolenie programistów jest kolejną oznaką tego, po jak dużej złożoności organizacyjnej muszą poruszać się zespoły programistyczne. W porównaniu z innymi rolami w firmie programiści bardziej lubią spędzać czas na rozwiązywaniu zawiłych problemów, a jednocześnie czują większą niechęć do wykonywania niepotrzebnych zadań, które w tym przeszkadzają. Niski poziom zadowolenia programistów jest dobrą oznaką, że złożoność organizacyjna jest problemem w zespole programistycznym.
Best for managing microservices: Compass
Compass is an ideal server management tool. It simplifies handling microservices architectures by putting disconnected data about engineering work and teamwork together in one central, searchable location.
Compass' features include:
- Get full visibility into service details with relevant APIs, libraries, documentation, key health metrics, latest deployment activities, on-call schedules, and more.
- Document and track upstream and downstream dependencies and understand performance impact across teams and services.
- View all incidents, deployments, and other critical activities for a service and its dependencies in one place.
Best for CI/CD: Bitbucket Pipelines
CI/CD is an acronym for continuous integration and continuous deployment.
Bitbucket Pipelines is a CI tool that automates processes. It works right out of the box with Bitbucket, an Atlassian cloud-based version control system. It can use code to manage pipelines, letting users commit pipeline definitions and start builds fast. Bitbucket Pipelines also has CD features that allow you to deploy projects to live infrastructure.
Part of the CI/CD development process is to build microservices. Bitbucket Pipelines fosters efficiency by simplifying workflows and integrating with Bitbucket's cloud version control system.
Best for ITSM: Jira Service Management
Jira Service Management is an add-on for Jira Software, a microservices-based application that lets you control IT services, such as incident, problem, and change management. Jira Service Management’s ITSM features allow IT teams to provide excellent service. There are several reasons why that is the case:
- Flexibility: JSM's collaborative approach can help streamline service delivery processes.
- Automation: The automation suite can help automate recurring tasks.
- Integration: JSM integrates seamlessly with other Atlassian tools.
- Security: It encrypts all data in transit using TLS 1.2+.
- Scalability: JSM is an agile ITSM product that can scale up to the enterprise level.
Best for documentation: Confluence
Confluence is a collaborative documentation tool. It’s ideal for creating and sharing documentation, critical in microservices architectures. Confluence offers a wide range of Confluence templates for various setups, including those using Kubernetes and Docker, a microservices tool that helps developers build, deploy, and run containers.
Confluence templates include multiple features and apps to help you capture, distribute, and update your technical documentation. Also, with Confluence, you can centralize all your documentation in one place and grant access to users only to what they need.
Best for bug tracking: Jira Software
Jira Software excels at bug tracking and project management. It provides a platform to track, prioritize, and resolve bugs effectively through an easily navigable interface. Jira Software's bug-tracking features contribute significantly to successful microservices management. They also address the potential for software sprawl.
With Jira Service Management, Jira's capabilities extend to streamline IT service management, including incident, problem, and change management within microservices and monolithic architecture.
Best for monitoring and logging: Prometheus
Prometheus is an open-source tool developers use to manage microservices. It collects extensive metrics, including counters, gauges, histograms, and summaries, that comprehensively view the application's performance. Prometheus also assists in real-time troubleshooting by providing a comprehensive monitoring and alerting system that enables developers and IT teams to identify and resolve issues promptly.
Best for testing microservices APIs: Postman
The distributed nature of microservices architectures significantly hamper traditional testing methodologies. Testing the entire system becomes complex and time-consuming because each microservice is an independent component. This is where a specific microservices testing tool like Postman comes in handy.
Postman simplifies the process of testing microservices APIs. Developers love that it can automate testing, enabling faster and more accurate results.
Some of the ways Postman simplifies the process of testing microservices APIs include:
- Visual request builder: Postman's visual request builder makes it easy to construct HTTP requests without writing code.
- Request collections: Postman allows you to organize your API requests into collections, making it easy to group related requests and share them with other team members.
- Predefined tests: Postman provides a library of predefined tests that you can use to validate the responses from your API requests.
- Test scripts: Postman allows you to write test scripts using JavaScript, giving you more control over your tests and enabling you to automate complex testing scenarios.
Jak sprawdzić, czy granica złożoności jest blisko
Osiągnięcie granicy złożoności wydaje się nieuniknione, ale istnieją oznaki pozwalające stwierdzić, że zespół zbliża się do niej. Najpierw jednak muszę zaznaczyć, że nie ma bezwzględnego wskaźnika, który pokazuje, ile dzieli Cię od granicy złożoności, jednak opisane poniżej oznaki mogą pomóc Ci w ustaleniu, ile zostało Ci do tej.
Najbardziej oczywistą oznaką, że zespół osiągnął granicę złożoności, jest to, że spędza więcej czasu na poruszaniu się po złożoności organizacyjnej niż na rozwiązywaniu zawiłych problemów, na których powinien się skupić. Przyjrzenie się tendencjom czasu wdrażania zmian (prędkość) i wskaźników błędnych zmian (jakość) wg DORA pozwala zorientować się, czy zespoły zwalniają, czy przyspieszają. Chociaż na te wskaźniki wpływają też inne elementy, są dobrą oznaką efektywności zespołu.
Zadowolenie programistów jest kolejną oznaką tego, po jak dużej złożoności organizacyjnej muszą poruszać się zespoły programistyczne. W porównaniu z innymi rolami w firmie programiści bardziej lubią spędzać czas na rozwiązywaniu zawiłych problemów, a jednocześnie czują większą niechęć do wykonywania niepotrzebnych zadań, które w tym przeszkadzają. Niski poziom zadowolenia programistów jest dobrą oznaką, że złożoność organizacyjna jest problemem w zespole programistycznym.
Podniesienie granicy złożoności
Why is monitoring and testing important in microservices architecture?
Aby przywrócić efektywność zespołu programistycznego, organizacje muszą podnieść granicę złożoności. Podniesienie granicy złożoności zasadniczo oznacza zwiększenie złożoności organizacyjnej do poziomu, którego przekroczenie negatywnie wpływa na działanie zespołu, zadowolenie z pracy oraz na jakość oprogramowania i szybkość jego dostarczania.
Inżynieria platform jest ważną koncepcją w dążeniu do podniesienia granicy złożoności organizacyjnej. Silne zespoły inżynierów platform koncentrują się na zmniejszaniu obciążenia poznawczego zespołów programistycznych poprzez oddzielenie złożoności organizacyjnej od ich codziennej pracy. Prawidłowo wdrożona inżynieria platform umożliwia zespołom zrównoważenie wielu wysiłków związanych z rozwiązywaniem zawiłych problemów dzięki mniejszej ilości czasu poświęcanego na poruszanie się po złożoności organizacyjnej.
What are some common challenges in monitoring microservices?
Właśnie po to w Atlassian powstała platforma środowiska programistycznego Compass. Compass pomaga w podniesieniu granicy złożoności, ułatwiając zespołom programistycznym poruszanie się po złożoności organizacyjnej poprzez katalog komponentów, wskaźniki i karty wyników oraz skupienie się na tworzeniu zdrowej kultury inżynieryjnej. W tym miejscu należy wyjaśnić, że w Atlassian złożoność organizacyjna nie zmniejszyła się, a wręcz nadal rosła, gdy organizacja stopniowo przenosiła się do architektury mikrousług. Ograniczyliśmy czas spędzany przez zespoły programistyczne na poruszaniu się po tej złożoności, bo na tym właśnie polega różnica między projektem upraszczania a podniesieniem granicy złożoności.
Atlassian zatrudnia ponad 10 000 pracowników i dysponuje ponad 17 000 komponentami oprogramowania, ale nasze zespoły programistyczne działają w dużej mierze ze swobodą startupów, szybko dostarczając wysokiej jakości oprogramowanie. Nasz klucz do sukcesu? Podniesienie granicy złożoności w celu poprawy efektywności zespołów programistycznych.
Podnoszenie granicy złożoności można rozpocząć od dwóch punktów:
- Śledzenie i ocenianie wskaźników DORA. Co wskaźniki DORA mówią o Twoim zespole? Jeśli jeszcze nie śledzisz wskaźników DORA, znajdziesz je w gotowej postaci w narzędziu Compass.
- Zrozumienie i ocenianie zadowolenia programistów. Jak się czują programiści w Twoich zespołach? Większość organizacji przeprowadza badania zadowolenia pracowników. Zapytaj o wyniki z podziałem na obszary funkcjonalne, aby uzyskać wgląd w zadowolenie programistów. Kluczowe pytania obejmują ocenę następujących stwierdzeń:
- W momencie dostarczania odczuwam dumę
- Ilość stresu w mojej pracy jest akceptowalna
- Rozumiem, w jaki sposób moja praca przyczynia się do realizacji celów firmy
Innym sposób polega na uzyskaniu tych informacji za pośrednictwem portalu Compass podczas rytuału CheckOps, w ramach którego zespoły dzielą się swoimi opiniami z ostatniego tygodnia i wskazują, co mogło pójść lepiej.
Podniesienie granicy złożoności wymaga połączenia narzędzi, procesów i rytuałów. Platforma środowiska programistycznego, taka jak Compass, może pomóc w zrozumieniu kondycji systemu, mapowaniu zależności i tworzeniu rytuałów, pomagając podnieść granicę złożoności i uwolnić potencjał zespołów dostarczających oprogramowanie w Twojej organizacji.
Wypróbuj Compass bezpłatnie już dziś.
What are some best practices for monitoring and testing microservices?
To test and monitor microservices effectively, use monitoring data, set the proper alert levels, automate tests, set up continuous integration and delivery pipelines, and regularly test their performance and security. These methods ensure that your platforms work reliably.
Join the Atlassian Community for more Microservices articles and discussions.
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.
Społeczność rozwiązania Compass
Samouczek: Tworzenie komponentu
