Close

Model CALMS

Oceń swoje umiejętności i mierz postępy w zakresie wdrażania DevOps.

Ian Buchanan

Główny inżynier ds. rozwiązań


CALMS to model oceny zdolności firmy do wdrażania procesów DevOps, a także sposób pomiaru postępów w transformacji DevOps. Akronim ten został ukuty przez Jeza Humble'a, współautora publikacji „DevOps. Światowej klasy zwinność, niezawodność i bezpieczeństwo w Twojej organizacji”, i oznacza Culture, Automation, Lean, Measurement oraz Sharing.

Kultura


DevOps to nie tylko proces czy inne podejście do programowania — to zmiana kultury. Podstawowym elementem kultury DevOps jest współpraca.

Żadna liczba narzędzi i automatyzacji nie pomoże, jeśli programiści i informatycy/administratorzy nie będą ze sobą współpracować. DevOps nie rozwiązuje problemów z narzędziami. Rozwiązuje problemy natury ludzkiej.

Pomyśl o metodyce DevOps jako o rozwinięciu Agile — różnica polega na tym, że DevOps w sposób domyślny uwzględnia operacje. Krokiem we właściwą stronę będzie utworzenie zespołów ukierunkowanych na produkt zamiast zespołów pełniących konkretne funkcje. Uwzględnij w zespole programistów, specjalistów ds. zapewniania jakości, kierowników produktu, projektantów, administratorów, kierowników projektu oraz osoby posiadające wszelkie inne umiejętności potrzebne w długofalowym projekcie. Zamiast tworzyć jeden zespół, który ma zajmować się wszystkim, lub zatrudniać „specjalistów DevOps”, lepiej jest tworzyć zespoły, które zajmują się konkretnymi produktami i które mogą ze sobą sprawnie współpracować.

Niewiele jest rzeczy, które wpływają na współpracę równie korzystnie, jak wspólny cel i plan jego osiągnięcia. W niektórych firmach nagłe przekształcenie zespołów na model ukierunkowany na konkretny produkt to zbyt duża i zbyt szybka zmiana. Warto więc osiągać cel mniejszymi krokami. Zespoły programistyczne mogą (i powinny) zapraszać wybranych administratorów, aby dołączali do sesji planowania sprintów, codziennych spotkań zespołu i demonstracji sprintów. Zespoły operacyjne mogą natomiast zapraszać na swoje spotkania kluczowych programistów. To zwinny i naturalny sposób, aby być na bieżąco z pracą, pomysłami i problemami kolegów.

materiały pokrewne

Dowiedz się więcej o zaletach DevOps

materiały pokrewne

Tworzenie kultury DevOps

Wyzwania, a nawet sytuacje awaryjne stanowią doskonały test kultury DevOps. Czy programiści, administratorzy i specjaliści wsparcia klienta zbierają się razem i rozwiązują problem jako zespół? Czy analiza post-mortem incydentów faktycznie koncentruje się na ograniczeniu skutków kolejnego incydentu, a nie szukaniu winnych? Jeśli odpowiedź brzmi „tak”, to znak, że Twoja organizacja rzeczywiście funkcjonuje zgodnie z kulturą DevOps.

W firmach, które osiągają największe sukcesy, wszystkie działy współpracują ze sobą w duchu kultury DevOps, która funkcjonuje na wszystkich poziomach schematu organizacji. Przy stosowaniu tego podejścia na tak dużą skalę termin „DevOps” jest często zbyt wąski, a tym samym zasadniczo zbędny. Takie firmy mają otwarte kanały komunikacyjne i regularnie się porozumiewają. Zakładają, że zespół programistyczny odpowiada za zadowolenie klienta w równym stopniu, co kierownictwo produktu. Mają świadomość, że DevOps to nie zadanie dla jednego zespołu. To zadanie dla wszystkich.

Automatyzacja


Automation helps eliminate repetitive manual work, yields repeatable processes, and creates reliable systems.

Build, test, deploy, and provisioning automation are typical starting points for teams who don’t have them in place already. And hey: what better reason for developers, testers, and operators to work together than building systems to benefit everyone?

Teams new to automation usually start with continuous delivery: the practice of running each code change through a gauntlet of automated tests — often facilitated by cloud-based infrastructure — then packaging up builds and promoting them through environments using automated deployments.

Why? Computers execute tests more rigorously and faithfully than humans. These tests catch bugs and security flaws sooner. And automated deployments alert IT/Ops about drift between environments, which reduces surprises when it’s time to release.

Another major contribution of DevOps is “configuration as code.” Developers strive to create modular, composable applications because they are more reliable and maintainable. That same thinking can be extended to the infrastructure that hosts them, whether it lives in the cloud or on the company's own network.

“Configuration as code” and “continuous delivery” aren’t the only types of automation seen in the DevOps world, but they’re worth special mention because they help break down the wall between development and operations. And when DevOps uses automated deploys to send thoroughly tested code to identically provisioned environments, “works on my machine!” becomes irrelevant.

Metodyka Lean


When we hear “lean” in the context of software, we usually think about eliminating low-value activities and moving quickly — being scrappy and agile. Even more relevant for DevOps are the concepts of continuous improvement and embracing failure — which lay the foundation of an experimental mindset.

A DevOps mindset recognizes opportunities for continuous improvement everywhere. Some are obvious, like holding regular retrospectives so your team’s processes can improve. Others are subtle, like A/B testing different on-boarding approaches for new users of your product.

We have agile development to thank for making continuous improvement a mainstream idea. Early adopters of the agile methodology proved that a simple product in the hands of customers today is more valuable than a perfect product in the hands of customers six months from now. If the product is improved continuously, customers will stick around.

And guess what: failure is inevitable. So you might as well set up your team to absorb it, recover, and learn from it (some call this “being anti-fragile”). At Atlassian, we believe that if you’re not failing once in a while, you’re not trying hard enough.

In the context of DevOps, failure is not a punishable offense. Teams assume that things are bound to go pear-shaped at some point, so they build for fast detection and rapid recovery. Postmortems focus on where processes fell down and how to strengthen them — not on which team member messed up the code. Why? Because continuous improvement and failure go hand in hand.

Pomiar


It’s hard to prove your continuous improvement efforts actually improve anything without data. Fortunately, there are loads of tools and technologies for measuring performance, like how much time users spend with your product, whether that blog post generated any sales, or how often critical alerts pop up in your logs.

Although you can measure just about anything, that doesn’t mean you have to (or should) measure everything. Take a page from agile development and start with the basics:

How long did it take to go from development to deployment?

How often do recurring bugs or failures happen?

How long does it take to recover after a system failure?

How many people are using your product right now?

How many users did you gain / lose this week?

With a solid foundation in place, it’s easier to capture sophisticated metrics around feature usage, customer journeys, and service level agreements (SLAs). The information you get comes in handy when it’s time for road mapping and spec’ing out your next big move.

All this juicy data will help your team make decisions, but it’s even more powerful when shared with other teams — especially teams in other departments. For example, your marketing team wants shiny new features they can sell. But meanwhile, you’re seeing high customer churn because the product is awash in technical debt. Providing user data that supports your roadmap — even if it’s light on features and heavy on fixes — makes it easier to build consensus and get buy-in from stakeholders.

Udostępnianie


As much as we wished that there was a magic wand to transform all teams into high-performing DevOps teams, DevOps transformations require a blend of practices, cultural philosophies, and tools. But like you’ve read, the benefits to breaking down the Development and Operations siloes are well worth it — increased trust, faster software releases, more reliable deployments, and a better feedback loop between teams and customers.

Embracing DevOps is no small task. Yet given the right mindset, effort, and tools, an organization can undergo a DevOps transformation that yields significant benefits.

The long-standing friction between development and operations teams is largely due to a lack of common ground. We believe that sharing responsibility and success goes a long way toward bridging that divide. Developers can win instant goodwill by helping to carry one of operations’ biggest burdens: the pager (a figurative construct these days). DevOps is big on the idea that the same people who build an application should be involved in shipping and running it.

In conclusion…


Out of this idea comes the phrase, "you built it, you run it," which fosters a hands-on approach accross teams. This doesn’t mean that you hire developers and simply expect them to be excellent operators as well. It means that developers and operators pair with each other throughout the application’s lifecycle. Moreover, reports have shown that peer-reviewed code and products are the only review that results in better delivery and performance; in fact, external reviewers were no more effective that conducting no review at all.

Teams that embrace DevOps often have a rotating role whereby developers address issues caught by end users while, at the same, troubleshooting production problems. This person responds to urgent customer-reported issues, creating patches when necessary, and works through the backlog of customer-reported defects. The “developer on support” learns a lot about how the application is used in the wild. And by being highly available to the operations team, the development teams build trust and mutual respect.

Ian Buchanan
Ian Buchanan

Ian Buchanan jest głównym inżynierem ds. rozwiązań DevOps w firmie Atlassian, skupiającym się na rozwijającej się społeczności DevOps oraz stosowaniu systemów Jira, Bitbucket i Bamboo w celu usprawniania ciągłej integracji oraz ciągłego dostarczania. Ian Buchanan ma szerokie i bogate doświadczenie zarówno w dziedzinie technologii Java, jak i .NET, ale najbardziej znany jest jako mistrz praktyk Lean i Agile w dużych przedsiębiorstwach.

W trakcie swojej kariery z powodzeniem zarządzał narzędziami do tworzenia oprogramowania dla przedsiębiorstw we wszystkich fazach ich cyklu życia — od początku aż do końca. Udało mu się doprowadzić do usprawnienia procesów w całej organizacji, czego efektem jest większa produktywność, wyższa jakość i większe zadowolenie klientów. Tworzył międzynarodowe zespoły Agile, które cenią sobie samorozwój i samodzielną organizację. Kiedy nie wygłasza prelekcji ani nie programuje, Ian oddaje się swoim pasjom związanym z parserami, metaprogramowaniem i językami dziedzinowymi.


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.

Ilustracja DevOps

Społeczność DevOps

Ilustracja DevOps

Ścieżka szkoleniowa DevOps

Ilustracja przedstawiająca mapę

Zacznij korzystać za darmo

Zapisz się do newslettera DevOps

Thank you for signing up