DevOps实战之探索篇（2）
推荐超级课程：
上一篇我们初步从人员角色的角度，对项目实施DevOps进行了探索。
本节，我们将按照我们上节分析的角色机能及其项目整体流程角度进行DevOps的架构流程设计。
1. DevOps的流程概要设计
此篇，我们将从上一章角色机能的角度出发，来初步勾勒和设计我们的DevOps需要设计的系统及其功能概要。
首先，我们来看整体的角色分配。在上一节中，我们将所有DevOps人员大致分为了以下几种角色：
管理人员
开发人员
测试人员
运维人员
市场销售人员
客户
DevOps人员
当然，在此我们只是列出一般的组织结构中涉及的人员角色，以此作为示例，而不是绝对如此。具体情况还要根据项目状况进行分析。
那么，作为DevOps重要实践之一，也是打破传统开发和运维的重要手段之一就是：良好的沟通反馈机制。
传统上，开发人员主要是和开发项目组的人员（包括管理人员）进行沟通，而运维人员主要和运维项目组人员进行沟通。双方之间的沟通很少，只有在问题发生的时候才会有更多交流。而现在，我们要在项目当中进行DevOps的实践，因此，我们要首先提供一个良好的沟通系统机制，这个系统中不仅开发和运维，还包括上述所有相关角色人员，大家能够实时、快速、准确的进行信息对等地沟通交流。
这很重要！！！
打个比方，即使开发人员和开发人员沟通，就Review（评审）代码而言，并不可能每个程序员都会在每个函数上写注释，也不是每个大牛都一定懂得菜鸟写出来的代码。换句话说，如何让不是程序员的运维人员向程序员准确地表述出程序运行时的状况和日志等相关信息，不仅对于程序员来讲，对于整个系统来讲都是至关重要的。
同时，这个系统不仅仅是为各种角色人员沟通反馈使用，而且还有一个重要的功能，就是能够及时甚至实时的反馈各种角色人员需要及时获取知道的信息，比如，运维系统的实时反馈，开发代码的质量分析，测试结果的反馈以及管理进度的状况报告等等等等。这些 “非人“ 的反馈信息，或者之后我们将讲到的”自动化流水线“反馈的信息，及时地反馈到系统中，为各类角色人员知悉，是整个DevOps系统的核心机能之一。
因此，对等、高效、实时的沟通反馈系统，是DevOps要实施设计的第一个流程组件。
1.1. 沟通反馈系统
首先，针对这个反馈系统，我们也需要进行角色权限设计。其中包括但不限于：
沟通反馈系统运维admin
管理人员组
开发组
测试组
运维组
市场组
客户组
DevOps组
其中反馈系统的运维管理员一般由DevOps组的人员进行担任。此角色主要进行：
- 人员的管理，包括增删改，已经一些相关权限的赋予等。
那么其他每个角色组按照他们各自的职责机能，创建相关的沟通频道，例如：
001_ProjectManagement 用来给管理人员进行项目进度管理沟通反馈使用。002_Dev01 用来给01开发组人员沟通反馈使用，等等。
同时，我们还需要为不同角色之间建立频道，包括但不限于：
管理人员和市场人员专用用的内部市场反馈频道
管理人员与客户组人员专用的客户关系频道
管理人员与项目相关小组leader专用的进度与任务反馈频道
开发测试运维专用的问题反馈频道
以上就是角色用的沟通反馈频道设计。
接下来，我们还需要为非人的机能进行反馈频道设计。这其中主要包括(但不限于)：
项目管理用的系统的信息反馈
代码管理系统的信息反馈
代码编译系统的信息反馈
成果物管理及部署信息的反馈
程序运行时系统的信息反馈
相关基础设施的运维信息反馈
项目所在领域趋势关注的信息反馈
这些“非人”信息的反馈在后面我们还会进行具体设计实施。在这里，我们主要列出作为DevOps实践人员应该要考虑的这些系统要素。
1.2. 项目管理系统
接下来，我们将按照之前角色的设计，自顶向下，进行需要的相关DevOps系统机能与流程设计。
我们需要为项目管理人员，包括其他角色人员提供统一的项目管理用的系统。该系统主要包括：
项目时间进度管理
项目任务管理
项目里程碑管理
项目相关知识体系管理
项目相关最新信息(包括客户，趋势)发布管理
等等
这些功能不仅仅只是为项目管理人员使用，还为其他角色人员提供角色权限范围内的机能。比如，管理人员可以进行项目任务的规划与调整，但是同时，开发人员能够查看分配给自己的任务详情及更新对应的进度状态。
整个项目体系使用统一的项目管理工具和流程，不仅是DevOps实践的最佳实践之一，同时也是Agile理论实践的最佳实践。
1.3. 代码管理系统
代码在一般的IT企业当中是最最重要的资产之一。所以，当然我们需要提供一个代码管理系统。
该系统不仅要满足必要的代码的版本管理，还应该具有更加便利的代码相关的机能，包括更友好的代码的评审机能，代码的阅读机能，代码的质量检测状态，以及代码相关的统计功能等。
现在的IT企业，随着云技术的不断发展，硬件以及网络等必要的基础设施也开始遵循IaaC（Infrastructure as code）这一最佳实践，所以包括基础设施代码，程序相关代码，甚至一些脚本等都需要代码系统进行良好的管理。
所以，不管是开发人员，还是运维人员，都需要这个系统，因此，这个代码系统还需要能够根据不同角色分配不同的权限和代码组织结构。以我们熟悉的Github来举例，它其实就是很好的代码管理系统。不仅仅是适用于个人的，开源的，同时，对于企业项目来讲，也是很好的系统应用。其实Github本身也提供企业版本的项目代码的管理服务。
1.4. 代码编译系统
这个系统，大家可能会比较觉得奇怪，编译系统？对！是的，我们需要一个统一具有权威性的编译系统。
该系统将对项目相关的代码进行代码进行编译，从而生成程序需要的成果物。
但是，该系统最重要的作用并不仅仅是编译。其作用包括：
统一编译环境。这样所有开发人员的代码不仅仅是只要本地电脑编译成功即可，而是需要在统一编译系统里面进行编译，如此统一编译环境， 以避免因不同编译环境导致的编译结果不同。
统一编译成果物处理。在编译系统中编译完成后，其成果物是需要发布到成果物管理系统管理还是需要直接部署到其他系统等等，将在编译系统编译后的后续步骤设置中进行统一管理。这样将其进行系统管理化，避免混乱的人为管理错误。
统一进行代码质量检测。熟悉Java的开发人员可能知道，我们需要利用checkstyle或者spotbug进行必要的静态代码检测，以保证代码的质量。该系统同样具有此功能，在此统一检测代码质量，以保证最终提交代码的质量。
统一进行必要的UT测试。如此也是为了保证代码的质量。传统的UT可能只需要本地开发人员执行后即可，在这里，我们也进行统一管理，统一报告，以标志最终代码的UT测试覆盖率与质量。
统一进行安全检测。这里的安全检测不仅仅是指代码的静态安全检测，比如代码的漏洞检测等。还包括，动态的程序检测。比如编译后的程序运行后，对其进行动态安全测试。
这里，大家会关注到一个词：统一。
没错，最重要的就是统一编译，统一检测，统一管理。只有这样，才能保证最终代码质量。不知道大家还记不记得第一节我们说到的，一个项目的所有开发人员也好，运维人员也好，不可能全部是大牛，所以如何保证最终的代码质量呢？这个编译系统就是其中要环之一。
1.5. 成果物管理系统
上一步我们提到了编译系统，编译系统编译后的成果物的化，我们也需要进行管理。以往，我们可能只是说保存到本地或者上传到某个存储空间中，然后以时间戳改名作为版本管理。而此系统，将对编译系统提交的成果物进行版本管理。
其实，这个可能对大家来讲并不陌生或者复杂，但是我们需要将它集成到DevOps系统当中，从而为项目进行服务。
这里，我们要注意的是，虽然我们现在在根据项目人员角色和机能的需要在进行DevOps系统机能的设计，但是，我们不要把每个系统进行孤立，最终我们需要把所有系统作为一个整体来实施。
1.6. 部署管理系统
该系统主要是用来对不同环境不同成果物进行部署。某种意义上讲，比较贴合当下的微服务的系统框架。
它能够更方便部署人员进行快速的不同环境的部署，当然这个部署动作一般情况下不是直接在部署管理系统进行的。
因为部署是一个十分重要的决定和动作！！！
因此，我们在前面几个系统流程中保证具备部署条件后，由Leader人员间接触发该系统的部署动作。简单讲，就是有一个部署的自动化流程，该流程最后一步的部署动作由该系统完成，但是，需要流程中的每一个环节达到部署的要求。从而保证部署的动作正确性。这就是部署系统的意义所在。
同时，根据不同的部署需求，技术架构人员可以在系统中实现必要的部署策略，比如蓝绿部署，灰度发布等。
1.7. 权限管理系统
以上所有系统，我们都需要进行必要的权限设计。因此，我们需要一个统一的权限管理系统。
该系统不仅仅是为某个系统进行权限角色设计使用，同时，它还是整个DevOps系统的权限入口。由此，进行中央集权式的权限管理，不仅可以简化权限的复杂性，同时，能够保证高效的权限执行。
1.8. 实时监视系统
所有系统，包括运行时的环境，都需要我们进行状态监控。而状态监控也是DevOps实施中一个必须而且重要的要素。
该系统不仅接收所有系统的状态反馈，同时进行统计和分析，并把状态进行尽可能简单和可视化展示。同时，结合其他系统，进行必要的监视报告的生成，甚至是自动化的运维流程的触发。
2. 小结
在此，我们做个小结。DevOps中，相信大家多少听过这个词：CICD。
对，持续集成和持续交付。那么这个词从意思上其实可能每个人都能够理解其中的概念，但是，作为DevOps人员，我们需要真正的为项目去实现CICD。因此，我们做了如上的这些系统设计。虽然，没有具体的代码或者“干干干们”所期待的实施步骤，但是，这些初步的功能概要设计与需求，是我们必须要理解并熟悉的，如此，我们才能进行进一步的实施。
至此，至少会让我们胸中有一定的蓝图概览，有谱了，对吧！
那么，接下来，就需要我们整合这些系统，并实现具体的CICD流程。当然，并不仅仅是CICD。在下一章，我们会逐步展开。