The devops handbook how to Create World-Class Agility, Reliability, & Security in Technology Organizations By Gene Kim, Jez Humble, Patrick Debois, and John Willis



Download 4,02 Mb.
Pdf ko'rish
bet49/57
Sana30.09.2022
Hajmi4,02 Mb.
#850974
1   ...   45   46   47   48   49   50   51   52   ...   57
Bog'liq
The DevOps Handbook How to Create World-Class Agility, Reliability, and Security in Technology Organizations ( PDFDrive )

 
Figure 12: 
Functional vs. market orientation 
Left: Functional orientation: all work flows through centralized IT Operations; Right: Market orientation: all 
product teams can deploy their loosely coupled components self-service into production. (Source: Humble, 
Molesky, and O’Reilly, 
Lean Enterprise
, Kindle edition, 4523 & 4592.
)
‡ 
For the remainder of this books, we will use 
service teams 
interchangeably with 
feature teams

product teams

development teams, 
and 
delivery teams
. The intent is to specify the team primarily 
developing, testing, and securing the code so that value is delivered to the customer.
Promo 
- Not 
for 
distribution 
or 
sale


84 • Part II
For example, high performance with a functional-oriented and centralized 
Operations group is possible, as long as service teams get what they need 
from Operations reliably and quickly (ideally on demand) and vice-versa. 
Many of the most admired DevOps organizations retain functional orientation 
of Operations, including Etsy, Google, and GitHub.
What these organizations have in common is a high-trust culture that enables 
all departments to work together effectively, where all work is transparently 
prioritized and there is sufficient slack in the system to allow high-priority 
work to be completed quickly. This is, in part, enabled by automated self-service 
platforms that build quality into the products everyone is building.
 
In the Lean manufacturing movement of the 1980s, many researchers were 
puzzled by Toyota’s functional orientation, which was at odds with the best 
practice of having cross-functional, market-oriented teams. They were so 
puzzled it was called “the second Toyota paradox.”
As Mike Rother wrote in 
Toyota Kata
, “As tempting as it seems, one cannot 
reorganize your way to continuous improvement and adaptiveness. What is 
decisive is not the form of the organization, but how people act and react. The 
roots of Toyota’s success lie not in its organizational structures, but in devel-
oping capability and habits in its people. It surprises many people, in fact, to 
find that Toyota is largely organized in a traditional, functional-department 
style.”
 It is this development of habits and capabilities in people and the 
workforce that are the focus of our next sections.
TESTING, OPERATIONS, AND SECURITY AS EVERYONE’S 
JOB, EVERY DAY
In high-performing organizations, everyone within the team shares a common 
goal—quality, availability, and security aren’t the responsibility of individual 
departments, but are a part of everyone’s job, every day. 
This means that the most urgent problem of the day may be working on or 
deploying a customer feature or fixing a Severity 1 production incident. Al-
ternatively, the day may require reviewing a fellow engineer’s change, applying 
emergency security patches to production servers, or making improvements 
so that fellow engineers are more productive.
Reflecting on shared goals between Development and Operations, Jody Mulkey, 
CTO at Ticketmaster, said, “For almost 25 years, I used an American football 
Promo 
- Not 
for 
distribution 
or 
sale


Chapter 7 • 85
metaphor to describe Dev and Ops. You know, Ops is defense, who keeps the 
other team from scoring, and Dev is offense, trying to score goals. And one 
day, I realized how flawed this metaphor was, because they never all play on 
the field at the same time. They’re not actually on the same team!”
He continued, “The analogy I use now is that Ops are the offensive linemen, 
and Dev are the ‘skill’ positions (like the quarterback and wide receivers) whose 
job it is to move the ball down the field—the job of Ops is to help make sure 
Dev has enough time to properly execute the plays.” 
A striking example of how shared pain can reinforce shared goals is when 
Facebook was undergoing enormous growth in 2009. They were experiencing 
significant problems related to code deployments—while not all issues caused 
customer-impacting issues, there was chronic firefighting and long hours. 
Pedro Canahuati, their director of production engineering, described a meeting 
full of Ops engineers where someone asked that all people not working on an 
incident close their laptops, and no one could.
One of the most significant things they did to help change the outcomes of 
deployments was to have all Facebook engineers, engineering managers, and 
architects rotate through on-call duty for the services they built. By doing 
this, everyone who worked on the service experienced visceral feedback on 
the upstream architectural and coding decisions they made, which made an 
enormous positive impact on the downstream outcomes.
ENABLE EVERY TEAM MEMBER TO BE A GENERALIST
In extreme cases of a functionally-oriented Operations organization, we have 
departments of specialists, such as network administrators, storage admin-
istrators, and so forth. When departments over-specialize, it causes 
siloization

which Dr. Spear describes as when departments “operate more like sovereign 
states.” Any complex operational activity then requires multiple handoffs 
and queues between the different areas of the infrastructure, leading to longer 
lead times (e.g., because every network change must be made by someone in 
the networking department).
Because we rely upon an ever increasing number of technologies, we must 
have engineers who have specialized and achieved mastery in the technology 
areas we need. However, we don’t want to create specialists who are “frozen 
in time,” only understanding and able to contribute to that one area of the 
value stream.
Promo 
- Not 
for 
distribution 
or 
sale


86 • Part II
One countermeasure is to enable and encourage every team member to be a 
generalist. We do this by providing opportunities for engineers to learn all 
the skills necessary to build and run the systems they are responsible for, and 
regularly rotating people through different roles. The term 
full stack engineer
is now commonly used (sometimes as a rich source of parody) to describe 
generalists who are familiar—at least have a general level of understanding—
with the entire application stack (e.g., application code, databases, operating 
systems, networking, cloud).

Download 4,02 Mb.

Do'stlaringiz bilan baham:
1   ...   45   46   47   48   49   50   51   52   ...   57




Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan ©hozir.org 2024
ma'muriyatiga murojaat qiling

kiriting | ro'yxatdan o'tish
    Bosh sahifa
юртда тантана
Боғда битган
Бугун юртда
Эшитганлар жилманглар
Эшитмадим деманглар
битган бодомлар
Yangiariq tumani
qitish marakazi
Raqamli texnologiyalar
ilishida muhokamadan
tasdiqqa tavsiya
tavsiya etilgan
iqtisodiyot kafedrasi
steiermarkischen landesregierung
asarlaringizni yuboring
o'zingizning asarlaringizni
Iltimos faqat
faqat o'zingizning
steierm rkischen
landesregierung fachabteilung
rkischen landesregierung
hamshira loyihasi
loyihasi mavsum
faolyatining oqibatlari
asosiy adabiyotlar
fakulteti ahborot
ahborot havfsizligi
havfsizligi kafedrasi
fanidan bo’yicha
fakulteti iqtisodiyot
boshqaruv fakulteti
chiqarishda boshqaruv
ishlab chiqarishda
iqtisodiyot fakultet
multiservis tarmoqlari
fanidan asosiy
Uzbek fanidan
mavzulari potok
asosidagi multiservis
'aliyyil a'ziym
billahil 'aliyyil
illaa billahil
quvvata illaa
falah' deganida
Kompyuter savodxonligi
bo’yicha mustaqil
'alal falah'
Hayya 'alal
'alas soloh
Hayya 'alas
mavsum boyicha


yuklab olish