DevOps实践之探索篇（1）
推荐超级课程：
上一篇我们讲解了DevOps的来源以及其基本概念。但是，这对于“干就完了”的程序员来说，未免过于啰嗦，甚至有人会觉得说这种文章网上同质文章一大堆，没有实干然并卵啊。
确实，这也是笔者最初的时候接触DevOps这些概念的时候的想法，所以，关于DevOps的一些常识性概念理论，我只在第一节中写出。同时，上一节的内容也浓缩了一些笔者实践经验后的一些DevOps的理论精华。
但百尺高楼起于垒土，我们还是需要这些的基础理论的。我们不会过多的细节的去描述Agile理论，精益方法或者这些与DevOps的具体异同细节等，但我们会在之后的课程中渗透这些理论概念。
之后，从此节开始，我们将以第一节的这些基本理论和最佳实践为基础，来逐步展开我们的DevOps企业级实践之旅。客官稍安 ;)
1. 正确迈出第一步
从DevOps这个单词当中，我们知道我们需要针对开发和运维两个团队或者角度作为出发点进行探索。
这很重要！ DevOps的最终目的是服务于企业或者团队，使其在项目中产生积极影响，并提高项目利润。如果我们连最终要服务的对象都搞不清楚，上来就撇出一堆流程设计或者工具箱，无异于本末倒置！
就好比上帝随便扔下来一个锤子，说“这是个很NB的锤子哦！”。但实际上只有雷神拿起来使用它，这个锤子才NB。一群凡人蜂拥而上，争相使用，结果都是一个字：靠！
因此，先搞清目标。不是因为有了锤子，才有了NB的雷神，而是因为有了雷神，上帝对他进行了身体基因的优化后，给了他这把锤子，让他NB和更加的NB。
这也是遵循我们DevOps最佳实践原则的第一条：
DevOps 是按照人员、流程和工具的顺序进行的。从工具开始将是错误的做法。
那么我们首先看下，DevOps需要关注哪些人员呢？
按照一般的不一般的IT企业结构来看，一个项目相关的人员，我们大致可以分为4类：
项目管理人员。主要进行项目管理，包括项目进度，作业分配，资源管理分配等。
开发人员。主要进行需求分析、设计与实现。
测试人员。主要进行产品（交付前）的测试。
运维人员。主要进行产品的运行时资源创建与维护以及产品的部署等。
销售人员。主要进行前期客户需求收集，同时进行产品方案的推销。
客户。终端用户，产品的使用者，甲方！
DevOps实施人员。
当然，其中根据项目状况不同，企业结构不同，肯定会有所差异，但是最主要的机能相关人员就是这些。而这些也是DevOps关注的人群。因此，我们将会着重分析这几类机能人员，以此为出发点，进行我们的DevOps实践。
这里大家会注意到，最后一个类别：DevOps实施人员。即我，你或者其他从事DevOps导入的人员。
为什么DevOps人员也要单独列出来呢？这里我们先不具体说明原因，本身我们作为DevOps人员，我们将分析前面几种人员为什么需要我们，我们怎么解决他们的需求或者改善他们的工作，从而最终来证明我们存在的意义。正如哲人所说：存在是有原因的！
（ 画外音： 注意不是某些四级都没过的人翻译的“存在即合理”哦，读书少的人，小心被骗！）
2. 项目人员机能分析
我们从2方面来分析这些人员：
作业内容
权限范围
来简化这些人员角色在DevOps化过程中，DevOps人员需要关注的要素。我们不会过于细致的去描述每个角色的具体工作内容以及他们的权限职责，因为这些一方面是因项目而差异，同时，一方面DevOps也不是神，也不是来考察每个角色的具体工作细节。而是通过关注角色的主要机能来了解这些角色，然后，为角色创建DevOps文化，提供适合他们的DevOps服务及流程设计。
每个人都是不一样的，每个项目都是不一样的，每个公司也是不一样的。
天下也没有一统的DevOps文化及其模板。
2.1. 产品方案销售人员
我们先来看产品销售售人员，为什么呢？因为我们项目之所以能够获得这个产品开发项目的前提是：我们获得了客户的信任。而获得客户的任务，最开始主要是由产品的销售人员完成的。
这也就是说，销售人员是第一个和客户或者说终端用户进行接触的人员。所以他们的信息传递很重要。因为第一印象和最终印象遥相呼应。
所以，在最开始的时候，销售人员的主要任务是学习了解掌握我们产品开发方案以及其优势。同时，向客户传递项目方案中DevOps的优势及其价值。因为并不是所有的公司的开发方案都有DevOps。因此，DevOps也应是销售人员睡服客户的重要武器之一。
不管是产品终端类型的客户，还是外包类项目的客户，让客户认识到DevOps的存在，了解DevOps，进而对DevOps充满期待，对项目来讲是至关重要的。因为，毕竟DevOps前期是需要投资的（包括人员，时间等）。让客户了解到，这些投资会持续的为项目打造出完美的成果物服务，同时会为客户提供非一般的服务感受，并且，持续完善的DevOps体系未来还具有可复用性，可谓一石二鸟。。。三鸟。。。四五六。
那么同时，销售人员，作为最前战线的人员，会获得第一手的客户情报，无论是关于产品需求的，产品反馈的，还是其他意见建议乃至褒贬之词等，这些都有助于项目管理人员更有目的性的为客户提供优质服务，改善项目管理缺陷，以及调整开发作业和进度，从而更快更好的输出客户价值。
以上主要是分析销售人员的工作内容。
关于其权限范围，从项目角度来看的话，销售人员主要是负责与客户进行沟通，向项目管理人员提供情报。那么他的权限范围偏向于项目管理范畴中的客户关系与情报管理。与其他类别人员角色，直接交集微乎其微。
其关系范围可以下面简图示例：
flowchart TD
subgraph 乙方
项目管理人员 o-.-o 销售人员
end
subgraph 甲方
客户 o--o 销售人员
end
备注的而重要的话
到这里，有的人可能会问：为什么要第一个分析销售人员呢？好像销售人员跟项目开发没啥关系吧。。。
不应该客户第一吗，客户是上帝嘛！
等等诸如此类的言辞。
这里，确实，第一个来分析销售人员笔者也是有私心的 ;)
因为长久以来，大家都慢慢的把销售这个冲锋在前的英雄战士的价值褪去了。尤其是IT行业，很多人都认为最NB的，最重要的就是技术好的人材。然而，忽视销售这群人材的存在价值是完全错误的。不论什么公司，什么规模的公司，销售人材永远是第一要招揽的人材。酒香也怕巷子深啊！ 以前农村的大街小巷的墙上喷的广告不是百度就是京东，不是小米就是华为。。。。。。
你觉得你的公司很NB，如果没有销售，你不会知道你的公司NB，因为没有客户知道你的公司NB。
换个角度讲，其实大家所认为的一些高高在上level的高管，比如CTO，CEO等等，这些人，最重要的角色和承担的任务就是销售。他们不仅仅是担任销售人员，同时还是公司的代言人。
因此，在这里，也是告诉大家，DevOps里面的重要原则之一：要建立互相尊重，互相支持，目标一致的团结的团队。
而销售人员也是整个团队不可或缺的一员。他们获取客户，获取情报，同时，将项目团队的其他角色价值“吹嘘”的灌输给客户。而同时，销售人员的终极目的是让客户能够长期与团队进行合作，要做到这一点，销售人员往往会拼命的挖掘客户的真实内心想法，无论是对产品的，还是对团队评价的，等等。这样，他们就像指路明灯一样，给团队指正方向。
而不是一些开发人员或者其他人眼中的无关紧要，来提无理需求的人。对于销售人员提出的需求或者建议也好，一定要好好分析，因为有可能就因为这个小小改变，成为客户长期信赖的伙伴，甚至获得更多潜在的客户认可。
因此，总而言之：所有的角色人员都是平等的，缺一不可。
作为DevOps人员，尤其要认清和贯彻这一点。要考虑到如何为销售人员提供适合他们角色任务的DevOps服务。那么，从以上来分析的话，我们可以为他们提供丝滑的与客户和项目管理人员沟通的渠道，提供他们合适的情报管理系统，提供适合他们角色权限的项目资料的快捷访问等。
2.2. 项目管理人员
项目管理人员相当于项目开发流程的第一入口，也是第一责任人。他的作业内容主要是进行项目的管理了。当然，这个项目管理任务包含很多纷杂的内容了，其中我们最关注和在意的一些包括：
需求分析
任务调度
时间进度安排
阶段性Release的管理
人员资源的管理
权限的分配管理
成本的控制
等等。当然，还有一条重要的工作就是和客户进行保持沟通，维持良好的关系。
这些，对于项目管理人员来讲都是很复杂而重要的工作。那么，除了项目管理人员发挥自身的该有的绝技之外，作为DevOps人员，我们也需考虑如何为项目管理人员进行量身定制的服务设计，包括管理流程和方法，各个时间线、里程碑的无缝衔接机制，完善方便的权限管理机制，实时方便的与客户及项目相关人员沟通的机制等等。
而对于管理人员的权限范围来讲，他就是就是我们乙方的全权代表了。用下图示例：
flowchart TD
subgraph 乙方
项目管理人员 --> DevOps人员
项目管理人员 --> 开发人员
项目管理人员 --> 测试人员
项目管理人员 --> 运维人员
项目管理人员 o-.-o 销售人员
end
subgraph 甲方
客户 o--o 销售人员
客户 o--o 项目管理人员
end
2.3. 开发人员
对于开发人员来讲，大家更加熟悉了。主要的工作内容就是对项目分配的Task进行实际代码的架构设计，编写，代码的评审，代码的提交，代码的编译，以及最终代码的编译成果物的提交等。
也就是说，对于开发人员来讲，代码就是一切，代码就是生命！代码就是饭碗啊。
古人讲：民以食为天！这也是，为什么开发人员一般被称为：码农。
那么，同样，代码对于项目来讲也是十分重要的，因为最终给客户的成果物就是代码或者代码编译后的成果物嘛。
因此，项目会广招天下能写出精良代码的英才来充实自己的队伍。当然，不可能项目内的所有人员都是写代码的天才，再说，项目管理人员从成本上来考虑，也不可能所有人都是英才。太贵了！！！21世纪什么最贵？人材啊！！！啊！！！
因此最为DevOps人员，要为主上分忧啊。这是臣子的本分啊o
考虑如何帮助开发人员在其作业范围内进行最终代码质量的控制。使得不是或者不全是英才的队伍写出天才质量的代码。同时，不能耗费他们元神。
不能拖延项目的进度，不能降低开发的热情，还能让他们升职加薪。。。（想多了哈）
那么关于开发人员的权限范围，其实就显得单纯的多了。主要是和开发相关的权限就可以了，比如代码的管理权限，当然，这里也要按照不同level进行适当的分配，毕竟，开发人员一般是整个项目团队里人员数量比重最大的，甚至会分为很多个不同模块机能的开发组。同时，同样开发组内，不同技术水平的人员对代码的控制也是不一样的，比如大牛会帮助菜鸟在其代码达到一定质量后才能提交等。
那么同时，开发人员可能还需要一些访问基础设施环境资源的权限，来自测他们的成果物或者进行Bug修正时的复现及检验等。
同时，一般开发队伍里还会有一个专门的质量保证即QA队伍人员。他们会检证以及评审代码的质量以及代码的方案。保证最终成果物的质量。在DevOps体系里，我们把它都归结为开发里的人员，只不过其中一项重要职责就是质量保证。
2.4. 测试人员
测试人员主要是对开发人员开发的成果物进行发布前的测试，目的是测试程序机能的正确性，并尽可能的找出程序的Bug。
从而保证最终发布的程序的质量。
最初的时候，很多测试人员都是黑盒测试。也即功能性测试。不会关注于代码本身的健壮性等等。后来，出现了白盒测试，使得对测试人员的要求也进一步提高了些。而目前，大部分的白盒测试的编写有时是依赖于开发人员的，但我们还是把他们作为测试人员的角色。
最终，测试人员的角色相对于开发人员，不管是作业内容还是权限范围都更加单纯了些。主要涉及测试成果物的访问权限，以及必要的测试环境的访问权限。
而从DevOps的角度讲，我们需要考虑如何让测试人员的报告更加清晰方便的传递到开发侧，减少测试与开发的沟通成本。同时，尽可能的用适合的系统和工具为测试人员提供方便的测试流程或工具，使得工作效率更加提高。毕竟，测试的任务量，一般来讲是不亚于开发甚至要高于开发的时间成本的。
2.5. 运维人员
运维人员，作为DevOps的半壁单词江山，可见其在DevOps领域的重要性。
其实，之所以如此，主要是因为运维的主要工作内容就是提供创建和维护开发人员开发的程序的运行时环境。程序没有环境运行，无异于我们说的行尸走肉、没有灵魂的好看的皮囊。。。
创建环境，包括环境架构的设计，资源的整合等等。然后将开发人员和测试人员测试后的程序部署到对应环境上运行，最后，对应用程序以及环境进行必要的指标性监控，也就是我们说的维护方面的工作内容。
而运维人员也是和开发人员打交道最频繁的角色之一。当然，按照以前传统的项目开发管理方式，这种交道，可以理解为嘴炮，互相抵制等等。而敏捷方法论管理方式普适以后，两者之间的交道范围有所拓宽，关系有所缓解，但还是不够充分，双方的信任度，理解度以及沟通的充分性还十分欠缺。这些问题也是DevOps着重需要解决的问题，无论是采用流程上的设计改善，还是制度文化上的变革，否则DevOps的存在意义也就不是很大了。
而运维人员作为与开发人员鱼水关系的亲人，其权限范围自然也是比较重要的，毕竟掌握了程序的生死。那么运维人员在获得这些资源权限的同时，其权限的可靠性以及安全性就变得十分重要了。
2.6. 客户
最后，我们来分析一下我们的客户。
这里，我们不去分析客户的工作内容和权限，因为这个角色的特殊性，这些对我们来说不是关注的重点。
这里，我们了解一下客户作为客户来讲，对我们项目人员或者我们公司这个团队的期待以及如何满足他们的期待。
客户对我们的期待，无外乎是最终提供他们满意的服务或产品。
而从开始设计到最终量产，这本身就是一个复杂且耗时系统工程。而在这个过程当中，如何让客户保持住【我们能够提供给他们满意的成果】的信念及信赖，不光是销售人员，项目管理人员需要一直考虑和做的事情，同时，也是DevOps人员必须要考虑的事情。
2.7. DevOps人员
最最最后，我们回到我们自身的角色：DevOps人员。
为什么要独立出来DevOps人员这个角色呢？
因为，通过分析以上人员角色我们发现，DevOps需要解决和实现的东西，是涵盖了其他整个项目人员角色相关的系统。不仅仅是相关的业务范畴，还包括不同角色的技能及权限范畴。
也就是说，如果让开发人员这个角色来实现DevOps，那么，他不仅仅只是需要具有开发人员的技能经验，还需要他具有运维人员相关的经验，测试人员相关的经验以及项目管理人员角色相关的经验等等等等。如此的话，可以看出，无论让哪个角色来兼任这个DevOps角色是不可能的。
所以，项目需要单独出DevOps人员这个角色。
而这个角色会和其他角色一样，从项目最初就开始参与到项目当中，然后为项目提供文化上，流程上，以及管理方法上的服务，使得整个项目进展的更加丝滑，使最终的成果质量更高，使客户更认可项目的价值。这就是DevOps的终极使命。
那么如此说来，DevOps人员的主要工作内容就包括：
项目DevOps文化的建立
项目管理流程及方法的设计改善
项目开发、测试、运维流程及方法的设计改善
项目相关角色间沟通反馈流程及方法的设计及改善
而从其权限范围来看，其权限既独立于其他角色权限，又统合其他角色权限。不会产生角色间权限的冲突。
3. 昂首挺进下一步
分析了这些之后，我们终于大致定格了我们DevOps人员的定位，接下来，我们就要具体化我们的任务和职责。
抬头挺胸，阔步向前！
但同时，步子也不要买太大~~容易扯着嘛 >.<