本文章讲解关于你想了解的所有DevOps实践都在这里和devops 都在那里的相关题，希望一定能帮助到大家。
【51CTOcom原稿】随着互联网行业的快速发展，IT研发的工作方式变得更加灵活多变。从应用的角度来看，处理的数据量和类型也在不断增加，从原来的单服务应用发展到现在的微服务应用。
从团队角度来看，这不仅包括开发和测试人员，还包括运营、安全、系统、网络等专家的人员。
因此，在新时代，用DevOps开发和运维方法论来指导交付过程就显得尤为重要。
让我们从DevOps的两个要点和三个原则开始，探索组织、团队和流程的实践。
DevOps的两个要点和三个原则
你所做的一切都是有价值的，而做事的过程就是将商业理念转化为客户价值的过程。
研发团队也有技术价值流。通过“开发+运维”的敏捷迭代为用户创造价值。技术价值流是第一点。
我们帮助开发和运营商业理念，以满足客户需求。
创建价值流可以分为两个步骤
第一步是设计和开发。
第二阶段是测试、运营和维护。
创造技术价值流的两个步骤
前置时间是客户提出需求的时间总和，我们创建工作订单来解决该需求，然后处理工作订单直到工作完成。交货时间是我们需要注意的第二点。
部署提前期和处理时间
它通常涉及设计、开发、测试、运营和维护等许多复杂而漫长的过程。
交付过程复杂且漫长。
我们想要实现的是不断提交小批量代码进行代码版本控制。每个提交在部署到生产之前都会经过自动编译、自动测试、手动测试和探索性测试。
为了实现这一目标，我们需要通过尽可能减少设计、开发、测试和上市时间来为客户提供的技术价值流。
基于上述两点，以下三个DevOps原则是选择
流动原理
我们将加快开发Dev和运维Ops之间的流程，缩短从开发到发布的时间，提高服务质量和可靠性。我们来看看需要注意什么。
让作品脱颖而出
软件开发行业的职位知名度没有传统行业高。通常，您只能看到完全完成后才可用的用户界面，并且即使某些后台服务完成后，您也无法看到它们的样子。
然而，人类很难控制看不见的东西，所以我们需要将我们的工作可视化。
敏捷开发通过减少每个阶段的工作来支持项目推荐和软件开发的完成。
开发、运维、UAT、全流程交付
同时，我们需要让我们的团队知道，只有在软件交付给用户并为他们提供价值之前，工作才算完成。
一个人可以同时执行的任务数量。
当你开发一个特定的功能时，一位测试人员报告了一个迫切需要修复的错误，同时产品经理进来告诉你这个需求可能需要更改。建筑师也在寻找这一点。谈论重构。
这迫使一个人同时处理许多任务，每项任务都很重要并且必须立即完成。这就像摊了馅饼，什么都做了，却没有把每件事都做好。不断地被打扰和任务之间的切换会降低生产力。
因此，需要利用看板来控制每个人的工作量，保持合理的任务数量，以保证质量和效率。
一个人执行多项任务
减少批量
我们在开发过程中经常会遇到这样的情况，一个有四个步骤，我们需要完成其中的100个。
因此，基于抽象和分工的原则，这个题被分为四个步骤，每个步骤分配一个人来完成，每个步骤完成100次才能完成该题。
这并没有什么题，但在早期阶段最好让每个人都一一完成本节的四个步骤，检查是否存在潜在的题，看看是否会出现题。我们总结了您在完成过程中会遇到的经验和陷阱。
当你解决了一些题后，你会找到其他人可以一步一步地帮助你。这种方法被那些试图快速犯错误的互联网公司广泛采用。
先完成闭环流程，再重现体验。
减少交接次数
当我们完成某件事时，我们经常会与其他团队或人进行大量的沟通、请求、委托、提醒、协调等。
例如在软件发布过程中，您需要执行功能测试、集成测试、环境搭建、服务器配置、存储管理、网络等任务。当一切都需要审查时，协调不可避免地会降低工作效率。
在这里你可以学习互联网公司的扁平化管理。每个团队都包含来自多个学科的技术、业务、管理和人力资源，从而减少跨部门沟通，提高工作效率。
减少交接
识别并改进局限性
软件开发和交付过程中存在很多，包括人力、时间、软件、服务器、网络等。
DevOps也是如此。必须不断识别并不断改进这些，以推进整体开发过程。
允许约束点之间平滑过渡
环境部署我们建议使用自动环境部署，并使用当前容器技术Docker，以加快整体环境部署速度。
代码部署考虑自动化代码上传、编译和部署。这项工作每天由我们的软件交付团队持续完成。开发团队中的人员越多，您就越需要执行此操作。
运行测试这是上一点的延续。软件发布后，必须接受自动化测试。
使用自动化脚本测试至少20个核心功能后，测试人员对特定功能进行冒烟测试。
随着软件功能的扩展，测试工作量也随之增加。如果没有自动化测试，依赖手动测试的工作量将是巨大的。
解耦架构由于微服务的流行，现在默认采用基于组件的设计。如果某个组件出现题，则还必须通过实施故障隔离和断路器机制来释放该组件。
反馈原则
如果说流程原则是指从开发到运维的快速流程，那么反馈原则就是从运维到开发的快速反馈。这两个原则将继续致力于为我们的客户提供最好、最快的软件服务。
及时发现题
服务/产品交付经历了从需求分析、原型设计、架构设计、编码、测试、发布、集成测试、验收测试到发布的各个过程。
工人参与每一步。每个题都有一个原因。即使是无法预防的题也能很快被发现并暴露出来。
例如，产品经理在开发过程中如果不充析需求，可能会遇到不明确的需求。此时，程序员可以提出题，产品经理应该明确需求。
题发现、题反馈、题解决流程图
解决分析题
存在这样的情况开发过程中发现的题并没有在需求和设计中提及。如果出现错误不加以控制，显然会影响系统的运行。
如果我们对自己采取不体贴的态度，题就永远不会被发现。当题出现时我们应该如何应对？
首先，如果上游链路出现题，不应该导致下游链路出现题。请参考上游链接进行故障排除。
上游链路有题
二是停止上游环节的工作，防止新题继续出现。
出现题及时处理。
第三，建立PDCA环，采取规划、实施、检查和改进行动，防止这些题再次发生。
PDCA机制建立
原产地品质有保证。
来源是什么？相对于下游，上游才是源头。产品经理是开发的源泉，如果需求的质量没有通过代码实现，就会受到影响。
程序员是测试人员的来源。如果程序质量出现题，测试就会受到影响。如果您忽视题，您将无法为客户提供价值。
因此，保证货源就意味着保证交付质量。每个过程、每个步骤的监控都是我们需要关注的。
需求阶段审查需求、确认需求、呈现需求
开发阶段代码审查、结对编程、单元测试。
测试阶段冒烟测试、回归测试、验收测试。
发布阶段自动配置、自动部署、自动检测。
原产地图表追踪
顾客同理心
客户有两种类型内部客户和外部客户。外部客户是一般意义上的客户。我们向客户提供软件，满足他们的需求并为他们创造价值。
内部客户是我们的下游客户。产品经理将开发人员视为客户，开发人员将测试人员视为客户。
当我们采取行动、发现题或做出决定时，我们需要考虑我们的“客户”以及这是否对他们有利。我们必须从客户的角度看题。现在很多题都会得到解决。
从客户的角度来看，客户在哪里？
学习原则
学习原则支撑着前两个原则，是基本原则。无论你在工作中面临多少挑战，或者在编码时经历多少失败，永远不要忘记，持续学习使人变得更强大，团队变得成熟。
建立学习型组织体系
无论您在提供服务时多么小心谨慎，错误都无法避免。每个人都经历过批评。
例如，如果产品经理没有清楚地解释某个具体需求，但程序员在实现过程中忽略了它，那么项目经理就会责怪开发人员。
刚开始工作的时候，这样的情况经常发生。后来，随着我领导的项目越来越多，我发现这种“指责”解决题的方法是错误的。
需要从题本身入手，找到题的原因。概述和定义流程和机制将确保您的兄弟不会再犯类似的错误。
通过将组织分为三个部分，我们希望它成为一个充满活力的学习型组织。
组织类型分类
病理型组织成员感到非常受到威胁，害怕做错事。每个人都拒绝承担责任，甚至隐瞒真相和事实来保护自己。
官僚型规则多，流程严格，大家都得自生自灭。
主动学习型不断总结错误，持续学习，持续改进。大家积极探索，勇于承担责任，乐于分享。
一个充满活力的组织是我们的目标
日常工作制度化
这里的制度化并不是为了官僚主义而给每个人加上官僚主义。相反，这些制度的出现，是希望工作中的兄弟将经验教训转化为制度的结果。其他兄弟绝对不会再踏入这些陷阱。
比如我之前发布的时候，总是忘记发布数据库脚本，导致生产环境程序无法运行。后来我们将数据库更新脚本写入到发布系统中，作为发布前必须执行的任务。
后来写成了自动化脚本，用于自动发布。其实我在工作中有很多好的经历。如果你细心的话，你可以建立这些持续改进的机制，并成为隐性系统。其实我们日常编码中做的事情有很多是可以很好总结的。
例子包括编码标准、命名标准、标准MVP/MVC/MVVM编写方法、发布流程、测试用例和测试脚本等。
系统服务流程
本土经验全化
在开发/运维过程中，我们经常会遇到各种事件陷阱。这些事件可以很容易解决，也可以造成长期题。
然而，在最终解决方案之后，我们希望将这些经验存储在我们的知识库中。这是我们共同经历的一笔财富。
其实在完成一个项目之后，自己从这个项目中学到了什么，就是这些经验的积累。
当你正在寻找下一份工作时，面试官你遇到过的最困难的题是什么，你可以自豪地分享这些经历。
无论您的经验有多么少，考虑您的观点都可以帮助激励和帮助其他技术人员以及跨部门的技术人员。
知识库管理经验
弹性模注射
这里所说的灵活性有两层含义。一是指劳动力灵活性，二是指维护。
No Comment