-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
运维Ops #130
Comments
DevOps 最佳实践 读书笔记
导论
DevOps
3 DevOps 流程
○ 被任命的相关方 ○ 确定的业务需求 ○ 制定的交付路线图 ○ 选定的交付方案
○ 特性被细化为故事 ○ 确定的功能性或非功能性需求,并且伴随着度量规则 ○ 定义好的验收测试条件 ○ 确定好的技术需求 ○ 定义好的测试用例 ○ 源文件被保存在一个版本管理系统中
由于经常是多名开发人员在一起编写代码,而代码也会随着时间而改变,因此保持源代码文件和脚本的版本控制非常重要。 3.2.3 构建流程
○ 创建目标代码,并且错误日志中没有错误记录。 ○ 目标代码被存放在制品库中。 ○ 源代码已完成质量检查。 ○ 单元测试执行完成,测试结果无任何错误。 ○ 源代码被签入基线中。
○ 系统和集成测试被成功执行。 ○ 服务符合技术要求和度量要求。 ○ 技术验收测试执行完成,测试结果无任何错误。
○ 服务符合规定的功能性及非功能性需求和度量要求。 ○ 验收测试执行完成,测试结果无任何错误。
○ 安全的环境和数据。 ○ 执行管理任务。 ○ 预防事件发生。 ○ 观察并记录发生的事件。
○ 已建立的监控指南。 ○ 已定义的事件目录。 ○ 已装配的监控设施。 ○ 确定(潜在)的生产标准偏差。 ○ 已登记的事件。 ○ 服务报告。
4 DevOps 团队的组织模式
○ 业务线模式。在这种模式下 DevOps 团队只为一条业务线工作。 ○ 组合模式。这种模式基于应用程序组合中的各个应用来划分 DevOps 团队。 ○ 信息价值链模式。这个模式特别适用于信息提供商把信息池(information lake)转化为报告。
○ 目标为业务的商业市场。 ○ 目标为自然人的个人市场。 ○ 在器材、停车场、餐馆及其他服务领域中提供服务的设备公司。
|
5 流程蓝图
流程蓝图 流程蓝图是体系结构模型的一个例子。蓝图用一张图显示了在服务组织中使用哪些服务管理流程,以及在没有详细显示所有沟通路径的情况下,如何组织纵向和横向治理。 表 5-1 展示了一个 16 区域的服务管理模型。这个模型是通过 DevOps 流程完成的,对于每个组织来说都是非常有启发性的。如果流程没有被明确识别,那么也可以用可交付成果来完善这个 16 区域模型。为了简单明了起见,本文只阐明可交付成果。另外,DevOps 团队当然也可以在单元格中加入更多内容。 表 5-1 16 区域服务管理模型 这种管理模型的优势在于,它可以帮助您思考 DevOps 领域内有什么和没有什么。一旦有些内容被排除在 DevOps 领域之外,那么,可交付成果在哪里被覆盖就成了问题。 |
DevOps
The text was updated successfully, but these errors were encountered: