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).
Do'stlaringiz bilan baham: 
