DevOps环境下DBA的角色转型：数据库管理与持续集成的协同

需积分: 9 41 浏览量更新于2024-07-18 收藏 3.8MB PDF 举报

《DevOps、DBA与DBaaS：数据平台管理支持持续集成》是一本由迈克尔·C·库佩特撰写的专业书籍，着重探讨了在DevOps环境中，数据库管理员(DBA)如何管理和处理数据平台，以支持和优化整个应用程序开发生命周期中的持续集成、交付、测试和部署流程。在DevOps团队的视角中，DBA的角色被重新定义，他们不再被视为阻碍软件开发生命周期(SDLC)进度的孤立环节，而是作为关键参与者来提高效率。书中强调，DBA在DevOps中的角色包括以下几个方面： 1. **评估变更请求**：DBA负责检查和评估来自开发团队的变更请求，确保它们符合组织的最佳实践，同时防止对数据库性能产生负面影响和依赖对象的有效性受损。 2. **自动化与orchestration**：为了缩短发布周期并提升产品韧性，DBA需要应用自动化工具和技术，如自动化脚本和数据库配置管理工具，以减少手动操作，使数据库管理工作与DevOps流程无缝衔接。 3. **数据库平台管理**：DBA需要管理数据平台的访问权限和安全性，确保只有授权人员能够访问数据，并监控系统安全，防止潜在威胁。 4. **技术支持与故障排除**：在应用部署过程中，DBA负责进行释放活动，解决与数据库相关的任何问题，保障服务的稳定运行。 5. **DBaaS解决方案**：随着云计算的发展，DBaaS (Database-as-a-Service) 的引入让DBA能够更有效地管理云端数据库，减轻运维负担，同时提高响应速度和资源利用率。 6. **持续集成的支持**：DBA的工作不仅限于后期部署，还要积极参与到持续集成的过程中，通过提供实时的数据反馈和优化建议，协助开发团队构建更健壮的应用程序。《DevOps、DBA与DBaaS》这本书深入分析了DevOps文化下DBA如何与开发团队协作，以及如何利用现代技术和云服务，将数据库管理融入DevOps的流程中，以实现更快的开发速度、更高的产品质量和更好的整体性能。它对于任何希望理解和改进在DevOps框架下数据库管理实践的读者来说，都是一份宝贵的资源。

Chapter 1 | DevOps for DBAs

or development team members, although doing so may further improve appli-

cation performance. More importantly, it provides an exceptional value to

customers. Sharing performance metrics enables disparate teams to aggregate

their combined experiences and skills, producing opportunities for better

solutions than are possible individually. (Chapter

6 delves into a few nondata-

base examples of measuring customer experience and how to expand change

management to be a DevOps tool for application performance improvement.)

DevOps Success Metrics

Extending metrics beyond customer experience performance management,

DevOps introduces measures for software delivery efficiency, release cadence,

and success rate. Continuous code integration, automated testing, and con-

tinuous delivery have to be measured to determine success. Continuous inte-

gration checks how well newly introduced code operates with existing code,

measured by defects. Automated testing checks whether new or modified code

function is as defined in the use case and whether the code passes regres-

sion testing Continuous delivery/deployment checks how often code is released

into production (release cadence) and whether the code causes disruption,

tracked by incidents.

Customer Experience Performance Protectors

Holistically under standing the infrastructure and application architecture

provides opportunities to decrease cumulative degradation , which improves

customer experience (see Table

1-1 ). Even for a basic transaction flow, the

delivery level drops rapidly.

Table 1-1. Cumulative Degradation

Cumulative Degradation

Component Success %

Network 99.9%

Web server 99.7%

App server 98%

Database 97%

App server 98%

Web server 99.7%

Network 99%

Customer Experience: 91.58%

DevOps, DBAs, and DBaaS

Cumulative degradation rev eals why the IT five 9’s availability goal falls short

when measuring customer experience.

Application performance management (APM) can provide transactional perspec-

tives of customer experience, transaction times, and frequency, which provide a

framework to fully understand application performance across the infrastructure.

DBAs with this transparency level can shift to predictive analysis, allowing cor-

rections to be implemented before the customer notices. Even troubleshooting

becomes less problematic and faster because baseline variances can be repo rted

if predetermined thresholds are violated. Additionally, preproduction APM appli-

cation monitoring can identify code or infrastructure performance deficiencies

before release, preventing problems from getting into production.

CAMS

The acronym CAMS

, originally coined by Damon Edwards and John Willis in

2010, has been used by many authors to describe four essential elements nec-

essary for DevOps success, each in their own words. I intend also to describe

these facets within the CAMS framework.

Culture

Internationally recognized management guru Peter Drucker famously pro-

nounced, “Culture eats strategy for breakfast.” Culture presents a perplexing

challenge to DevOps implementation. Wanting to do DevOps by investing

in DevOps tools, training staff, and hiring expert consultants, all without a

transferal of mindset, behaviors, and incentives, only suppresses the status

quo, which lies quietly below the waves seeking an opportunity to re-emerge.

During a recent client call, a team brought forward a build request for two

virtual hosts, including software installs for several products from a popular

Agile tool suite. The conversation went something like this:

Requester: “We need two VMs with tool A and tool B installed for a

project starting in 10 days.”

SA: “Once approved, it takes 6 weeks to provision a VM.”

Requester: “This project has been approved by SVP what’s-her-name

and VP so-and-so as a fast-track project.”

SA: “Our process takes 6 weeks. Then someone still needs to install

the tools because that’s not what we do.”

HYPERLINK “ http://devops.com/2015/05/28/where

Chapter 1 | DevOps for DBAs

By this time, I am “cryaughing”—trying not to cry or laugh, but really wanting

to do both. But I digress.

Requester: “We are trying to be agile and need to move fast.”

SA: “Our process is fast! It used to take 3 months to get a host

provisioned.”

And so forth. Sadly, this is not a fictional story for book demonstration

purposes.

As this unfortunate yet emblematic example shows, existing processes create

cultures ingrained with supp ositions of how well teams are pe rforming, what

people believe are expected from them, and a “don’t rock the boat” mindset,

all of which present tremendous hurdles to be surmounted. DevOps requires

processes to be rethought, leaned out, sped up, and extraordinarily stable.

Pulling together strong and patient leaders, complemented by charismatic

and uber-respected technical subject matter experts (SMEs) such as DBAs

or senior DevOps engineers, to challenge the status quo by instigating a new

culture focused on DevOps best practices must be the movement’s heart

and soul. An organization’s culture must transform into a more collaborative,

process-defined, and people-centric entity to successfully drive continuous

improvement, automation, and integrated testing.

To change the culture, people must at least accept the new direction, even if

reluctantly. The best-case scenario includes people being only too happy to

scrap the old model and excited to move on to better methods. Both types

of people encountered need to be coached differently to effectively ensure

the movement’s success. The reluctantly accepting group drags its feet, in no

hurry to reach the new destination. Coaching increases the pace, improves

buy-in, and develops needed attitudes. The excited group (probably the ones

who have been telling each other for years that management is a cast of

morons and constantly bloviating about how everything would be awesome

if only they were in charge) can be more dangerous to the cause than those

who may be flat-out resisting the change. Failing to control the ascent w ith

planned and well-communicated phases that include needed staff training,

concrete process definitions, and general good change practices may result in

a catastrophic crash and burn.

Change is an interesting beast. A team member once asked his manager why

the manager had not pushed for a large change that needed to happen. The

manager responded that change done gradually over time usually receives

better acceptance. The manager’s example was for the team member to imag-

ine coming to work the next morning to find a full-grown tree in his cube.

The manager explained tha t even if the employee loved trees, the tree would

be bothersome because it had invaded his space unexpectedly. But if the team

member arrived to find a potted sapling on his desk, he might think it is cool.

DevOps, DBAs, and DBaaS

Over time, as he would nurture the sapling (even though he had to repot the

now small tree and place it on the floor), the team member would remain

comfortable with its presence. After a few years passed, when people would

ask him about the full-grown tree in his cube, he would proudly share that he

was able to transform a weak sapling into a mighty tree. The employee would

accept the change because he was involved (nurturing), and the change came

about slowly but consistently.

Driving the new DevOps culture requires introducing a “sapling” and nur-

t uring its growth until the “tree” is well rooted. The more people who are

involved in the nurturing process improves the odds of a positive outcome.

Leaving the tree-nurturing responsibility in the hands of only the core team

likely leads to a brown and wilted sapling.

Automation

It is odd to think that one of th e primary benefits unleashed at the dawn

of the computer era was the ability to reduce costs and processing time by

automating routine tasks. Yet today, when CIOs and their teams are under

pressure to drive strategic growth initiatives needed to increase revenue or

introduce new products for customers, much of the behind-the-scenes effort

is still completed manually. IT professionals (I, too, have been guilty of this)

love working with shiny new toys—often at the expense of reducing effort or

costs through automation.

DevOps is about speed, flexibility, resiliency, and continuous improvement.

People need to understand the processes, build and test the software, imple-

ment the automation, and then step back and let the computers do the work.

For DBAs, this means relinquishing control of the scripts and surrender-

ing them to source code control. The scripts now become included in the

release package instead of being manual executions listed as a task in a plan

spreadsheet.

Automation applies to server builds, database software installs and configura-

tions, network settings, storage allocations, schema builds, code compiles, job

scheduling, and more. Anything and everything should be automated. Security

programs should automatically scan hosts for vulnerabilitie s. Auto mation is the

way resiliency can be gained, reducing human error risks. The automation itself

needs to be monitored and measured to ensure it is delivering expected benefits.

Measurement

People live by measurements. O ur day (a measure) is an accumulation of

events segmented by the measure of time. The value of our contribution to

the organization comes periodically (a rhythm of measures): the a mount of

Chapter 1 | DevOps for DBAs

our paycheck. Hence, measurements must be important. Yet too many IT

shops still focus on binary checks, such as a server being up or down instead

of business measures such as end-user experience and transaction capability;

or for DevOps: cycle time, failure and resolution rates, release momentum,

feature time to market, and reduced SDLC costs.

For DevOps to succeed, a consistent whittling away at inefficiencies, avoidable

steps, and pointless multilevel approvals must occur. The burden of CYA and

sometimes ego boosting for less-mature executives (e.g., requiring ten people

to approve a change) has been known to be one of the most consuming yet

valueless requirements related to the SDLC. After all, the business made the

request and IT agreed to complete the work, which sounds like approvals. Yes,

other oversight is needed, but surely a few approvals would not be missed.

Applying lean and Kanban techniques trim inefficiencies that should return

value from reduced waste and improved speed. Process mapping, or value

stream mapping, should be don e to cap ture the delivery process, see how long

each step takes, and evaluate the need for each step. Decisions can then be

made to remove impediments, smooth out the workflow, and drop unneeded

steps and approvals to produce a streamlined SDLC process.

Sharing

“Knowledge is power.” That sa ying has been around for years, but has been

distorted; many people hoard information to be used only for personal gain

versus benefiting others. Someone who knows how to cure cancer does

not hav e power by selfishly retaining the solution; instead, the power comes

from releasing the information and then watching how the knowledge, when

applied, impacts people around the world.

DevOps breathes by sharing information. Business, development, and opera-

tions (including DBAs) must communicate in full-duplex. Messages need to

be sent and received simultaneously upstream and downstream. Each team

member must understand why the business needs the function and how the

business plans to use the function. Addressing operational challenges earlier

in the process leads to better-performing and resilient production systems. As

DevOps expounds continuous testing across the SDLC, all environments must

match the planned end-point state. Operational knowledge from team mem-

bers’ vast experience, aggregated into manageable bundles driven upstream to

improve the infrastructure, creates consistent and stable platforms.

Do you remember the grade school exercise in which the teacher would

share a sentence with one student that was then passed from student to stu-

dent until the last student relayed the sentence back to the teacher? Whether

it was changed intentionally for malice or fun, or changed because students

couldn’t remember the exact statement, the final message was usually so dis-

similar to the original sentence that it was humorous. Unfortunately, this is

剩余164页未读，继续阅读

tlforest

粉丝: 27
资源: 198

DevOps环境下DBA的角色转型：数据库管理与持续集成的协同

Azure DevOps Wiki快速转换PDF工具使用指南

探索Kubernetes与DBaaS在DevOps中的应用与权衡

快速获取DevOps认证，使用Python脚本生成PDF

DevOps, DBAs, and DBaaS(Apress,2016)

Devops调查报告.pdf

DevOps with Kubernetes 无水印pdf

DevOps for Dummies.pdf

DevOps开卷试题.pdf

DevOps实践探讨.pdf

DevOps for Developers.pdf

最新资源