构建DevOps文化：协作、团队亲和力与规模化工具选择

5星 · 超过95%的资源需积分: 9 90 浏览量更新于2024-07-21 4 收藏 6.7MB PDF 举报

《Effective DevOps：构建协作、归属与规模化工具》是一本实用指南，由Katherine Daniels和Jennifer Davis合著，于2015年出版。两位作者以其在实施和维护DevOps文化方面的经验和教训为基础，为读者提供了应对技术、文化和管理层面挑战的策略。本书重点关注个体间的协作、团队凝聚力、工具选择与开发以及如何在大型组织中实现DevOps的规模化。本书分为五个主要章节： 1. **引言**：介绍DevOps的核心理念和在当前IT环境中的重要性，以及本书的目的和结构。 2. **什么是DevOps**：详细解释DevOps的概念，包括其起源、目标和如何将开发和运维团队融合，以提高软件交付速度和质量。 3. **协作：个人工作方式的转变**：关注个人如何通过改进沟通、建立有效的工作流程和防止过度劳累来促进团队合作。书中包含实际案例，帮助读者理解不同组织规模和个人角色的最佳实践。 4. **招聘与团队建设**：探讨如何挑选具备DevOps理念的人员，并提供在组织中培养和发展这些技能的建议。这章涉及面试技巧和团队动态的管理。 5. **工具的选择与实施**：针对各种DevOps工具的类型、应用场景以及在选择或自建工具时要考虑的因素进行深入分析。本书会介绍不同工具的优缺点，帮助读者根据自身需求做出明智决策。此外，书中还提供了关于如何避免规模化过程中的常见陷阱以及如何将成功的策略推广到更大范围的实用策略。《Effective DevOps》不仅适合DevOps初学者，也是对现有实践者的一次深度提升，强调了在任何组织中推动持续改进的文化和工具的重要性。版权信息表明该书已获得版权保护，由O'Reilly Media出版，强调了在线获取资源的可能性以及作者保留所有权利的声明。这本书的编辑、生产、校对和设计团队也列出了他们的贡献。第一版于2015年发布，后续进行了修订以保持内容的最新性和实用性。

the idea that change is extremely risky. For the singletons in either group that tried to

make change to the overall processes, they’d find themselves stuck in the mire of

becoming the subject matter expert, locked into the positions of support that became

critical to maintain.

In 2001, an invite went out to folks interested and active in the Extreme Program‐

ming (XP) community and others within the field. XP was a form of Agile develop‐

ment that was designed to be more responsive to changing requirements than

previous development software methodologies, known for short release cycles, exten‐

sive testing, and pair programming. Seventeen software engineers got together in

Snowbird Utah to discuss software development. They summarized their shared

common values to capture the adaptiveness and response to change that they wanted

to see in development with an explicit emphasis on human factors. This Agile Mani‐

festo was the rallying cry that started the agile movement.

In 2004, Alistair Cockburn, a software developer who was one of the co-authors of

the Agile Manifesto, described Crystal Clear a software development methodology

for small teams based off of 10 years of research with successful teams. It described 3

common properties frequent delivery of usable code, reflective improvement, and

osmotic communication between developers. Crystal also described 3 priorities

safety, efficiency, and habitability.

This movement continued in software development for several years, and later began

to have its influence felt elsewhere. In 2006, Marcel Wegermann wrote an essay on

how to take the principles of Crystal Clear, Scrum, and Agile and applying them to

the field of system administration. Along with Agile and Scrum, it contained several

ideas that Wegermann argued could be applied to system administration as well as

software development, wanting to bring newer and better practices to the field. In

addition to giving a lightning talk on the subject where he suggested ideas such as

version control for the Linux operating system’s /etc directory, pair system adminis‐

tration, and operational retrospectives, he also started the Agile System Administra‐

tion mailing list.

As web technology continued to grow and evolve, the ways that people communica‐

ted and collaborated online did too. Twitter, an online social networking service was

introduced to the world not even a year later in 2006. At first it seemed very much

like a tool for people wanting to share information in an abbreviated format, for short

attention spans or for celebrities to reach out to fans. In 2007, however, the South by

Southwest Interactive conference saw the use of Twitter skyrocket as Twitter placed

screens in the hallways streaming twitter messages. Twitter quickly became a way for

ad-hoc communities to be formed across the globe. For conferences, it was a way to

get additional value out of the multi-track systems and connect with like minded

individuals. The hallway track, a phrase often used to describe the interactions and

conversations that take place in the hallways of conferences, had expanded from the

The History of Devops | 15

physical world to the web where anyone could discover and participate in these ad-

hoc interactions.

Agile Infrastructure

At the Agile 2008 conference in Toronto, Andrew Shafer, a former software developer

who was starting to take a great interest in IT concerns, proposed an Agile Infrastruc‐

ture session. At the same conference, Patrick Debois spoke on incorporating scrum

into operations “Agile Operations and Infrastructure: How Infra-gile are You?”. Pat‐

rick worked with development and operations teams on a project to test data center

migration. One day he would be working on agile development with the developers

and the next day he would be firefighting with the operations team leading to a lot of

context switching; the switching from one process or task to another. Context switch‐

ing for humans cost anywhere from 5 to 30 minutes in lost productivity per context

switch. Observing that he wasn’t the only one interested in Agile system administra‐

tion, Patrick contacted Andrew out of band to discuss agile system administration.

Around the same time, individual companies were beginning to not only make great

strides towards processes that allowed them to keep up with the increasingly rapid

changes of the internet, but were also beginning to share some of their stories pub‐

licly through communities that were building up around popular conferences like the

[O’Reilly Velocity Conference](http://velocityconf.com/).

One such company was Flickr, a popular community site for photographers. After

being purchased by Yahoo in 2005, Flickr needed to move all of the services and data

from Canada to the United States. John Allspaw, a web operations enthusiast who had

worked in systems operations for years, had joined the company as the Flickr Opera‐

tions Engineering Manager to help with its scaling and now was charged with this

massive migration. At the time, Flickr hosted over 3 billion photos with 40000 photos

being served per second. Paul Hammond joined the Flickr Development team in

2007, and became the Flickr Engineering manager in 2008 heading the development

org in collaboration with Allspaw.

Hammond and Allspaw co-presented at Velocity Santa Clara 2009 “10+ Deploys per

Day,” highlighting the revolutionary change that allowed the team to move rapidly.

They didn’t do this by setting out to break down silos or start a big professional and

cultural movement. They were able to collaborate a great deal in their work at Flickr,

which was in contrast to Allspaw’s previous experiences at Friendster, where emo‐

tions and pressures ran high and there was little in the way of inter-team collabora‐

tion. The opportunities to work together that presented themselves were something

that both managers took advantage of. Neither of them woke up one day and decided

that things needed a big change, but rather they recognized the little pieces of work‐

ing together that made things work well. They took note of these little things that

they did together, which ended up becoming much bigger cultural changes.

16 | Chapter 2: What is Devops?

The Beginning of DevopsDays

“Don’t just say no, you aren’t respecting other people’s problems… #velocityconf

#devops #workingtogether”

—Andrew Clay Shafer (@littleidea)

This tweet, from Andrew Shafer on June 23 2009, caused Patrick Debois to lament

that even though he was watching remotely, he was unable to attend that year’s Veloc‐

ity conference in person. Paul Nasrat, at the time a lead systems integrator at the

Guardian, tweeted in reply, “Why not organize your own Velocity event in Belgium”.

Inspired Patrick did just that, creating a local conference that would allow for devel‐

opers, system administrators, toolsmiths and others in those fields to come together.

In October of that year, the first DevopsDays conference took place in Ghent. Two

weeks later, he wrote:

“I’ll be honest, for the past few years, when I went to some of the Agile conferences, it

felt like preaching in the desert. I was kinda giving up, maybe the idea was too crazy:

developers and ops working together. But now, oh boy, the fire is really spreading.”

—Patrick Debois

That first DevopsDays event ignited the powder keg of unmet needs, people separated

in silos frustrated with the status quo identified with devops and a way of describing

the work they felt they were already doing. The conferences grew and spread as indi‐

viduals started up new DevOpsDays across the world. With the availability of the

real-time communication platform of twitter, the hallway track never ended and

#devops took on a life of its own.

As we reflect on history, we see the trend of a focus on the outcome. Many have seen

the “10+ deploys a day” presentation from John Allspaw and Paul Hammond and

taken away from it that the importance was the 10+ deploys per day, the quantity of

deployments in a day. The title “10+ deploys a day” was the hook which pulled people

in to see the presentation. The content of the talk how they achieved something that

seemed impossible and not a simple metric. You can’t declare “doing devops success‐

fully” simply because you are “doing 10 deploys a day”. This fixation on an outcome

increases the stress to the human who is already stressed out because workflow of the

organization doesn’t allow for the adventurous dedication and commitment enabled

with freedom and trust to be happy and productive humans building new leaps for

mankind. As we will show in later chapters, focusing on the processes is a better way

of thinking, because devops is about how we do things, and why, not just what we end

up doing with those things.

Foundational Devops Terminology and Concepts

In order to effectively discuss the tools and techniques required to implement devops,

it is necessary to define some of the major terms and concepts surrounding it. When

Foundational Devops Terminology and Concepts | 17

down on the number of mistakes that would be found later. Part of the appeal of this

stemmed from the high costs of delivering and changing software that was dis‐

tributed on CD-ROMs or floppy disks to be installed by hand. Since fixing a bug on

such software would require, for example, manufacturing and distributing another

CD-ROM with a software patch, it was much more cost-effective to spend the time to

get the design and specifications right up front.

The waterfall method makes sense in these cases where the cost of delivering software

is high or for projects with requirements unlikely to change. As with every methodol‐

ogy, the waterfall method has its pros and cons.

Some advantages of using the waterfall method is its emphasis on documentation,

discrete understandable phases and milestones. Documentation alleviates knowledge

lost when individuals leave or new employees join a project. With understandable

discrete phases, project members can finish a phase of the project and pass on to

other members at the significant milestones.

Project manager Mary Lotz has argued that gathering and specifying all requirements

in advance of any work being done is often the most difficult part of any software

development project. Customers often don’t know their exact requirements, at least

not enough to make sure that they are 100% completely specified, and requirements

will often change over time. As software is developed, limitations may be discovered

that cause requirements or deadlines to change.

Projects that require more flexibility might benefit from examining some more itera‐

tive or agile methodologies as well. As we will examine further in later chapters, a key

part of devops is being able to assess and evaluate different tools and processes to find

the most effective one for your environment, but it isn’t so rigidly defined as to pro‐

hibit any methodologies, even older ones such as waterfall.

Extreme Programming

• Communication

• Feedback

•

Simplicity

• Courage

• Respect

Lean

The idea of lean originally stemmed from lean manufacturing, which was a system

for eliminating waste within a manufacturing process. The Toyota Production System

of the 1990s, also called “Just In Time” production is perhaps the best-known exam‐

Foundational Devops Terminology and Concepts | 19

剩余154页未读，继续阅读

ramissue

粉丝: 354
资源: 1487

构建DevOps文化：协作、团队亲和力与规模化工具选择

OReilly.Effective.DevOps.Building.a.Culture.of.Collaboration.Affinity.and

Kantsev V. - Implementing DevOps on AWS - 2017.PDF

Effective DevOps Building a Culture of Collaboration, Affinity, and 无水印原版pdf

Agile.Application.Lifecycle.Management.Using.DevOps.epub

Implementing.DevOps.on.AWS.epub

Effective-DevOps-with-AWS:Packt发布的《使用AWS的有效DevOps》

Effective DevOps

Effective-DevOps-and-Development-with-Docker-V-:Packt出版的《有效利用Docker（V）进行DevOps和开发》

Python for DevOps Learn Ruthlessly Effective Automation.pdf

Effective DevOps Building a Culture of Collaboration, Affinity, and Tooling epub

最新资源