初创型公司的DevOps之路浅谈
本帖最后由 adminlily 于 2018-10-10 16:49 编辑写在前面的话
在现在这家互联网金融创业公司做运维快两年了，这两年里得到了很多人的支持和帮助。在这些帮助下，在这家初创型企业有限的资源里，搭建了一个集持续集成和交付、自动化监控和响应、资源管理和安全审计的自动化平台。在这样一个时间点，觉得是时候和大家一起分享一下在初创型企业中如何建立一种DevOps的企业文化，帮助企业实现快速的产品迭代、更好的收集用户反馈、准确的优化用户体验，使得企业能够在创业初期获得更多的竞争优势。另外，由于公司的IT架构都是基于AWS搭建的，而我本身所从事的岗位是运维，所以文章会从运维的角度集合AWS的服务去阐述DevOps。但是基本思路应该是具有共性的，大家可以结合自身的实际情况，发挥想象空间。另外想说的是，在云端，运维的时代已经来临。
DevOps的典型特征
进入正题，DevOps无疑可以帮助公司提高运转的效率，且大幅度节约成本。但是一家初创型公司在人力物力有限的前提下，如何实现DevOps呢？先来说说DevOps的典型特征：
特征1：快速的产品迭代
产品的迭代的能力对应的是一家初创型公司对市场的适应能力，更短的迭代周期意味着能够更快的实现用户需求，更快的修复产品缺陷，并且可以不断的去进行试错。那么，以多长时间为一个迭代周期更加合适呢？通过自动化的持续集成和持续交付平台，理论上如果研发能力够，是可以实现每分钟一次的产品交付的。但我认为比较合理的交付周期是1到2天。不是说不能更快，而是根据用户对于产品的要求决定的。拿电商来说，虽然如果能够实现当日购买，当日送达，当然是最好，但是第二天就能送到，也是不错的体验。当然，如果是紧急的BUG修复当然是越快越好。
产品迭代的整个流程涉及到需求的收集和提出、研发、部署、测试、验证、上线。虽然DevOps强调敏捷，但并不意味着可以为了节约时间而跨过这些关键的环节。这些环节中，运维为主导的部分有：需求的收集，运维需要根据监控数据提供优化建议，这块涉及监控相关的内容，放到后面再详聊；部署，运维需要建立自动化的部署流程；各环境的交付，代码从测试到预发布、再到生产上线，而在产品包的交付过程中，运维还需要完成各个环境的配置管理和变更。因为频繁的产品交付会涉及各个流程，并产生大量的工作，而过多的人工操作一定会降低交付质量。所以在快速的产品迭代过程中，自动化所有环节中的所有操作，才会显得至关重要。
特征2：自动化CI/CD流程
那在云端的产品交付如何来实现自动化呢？在使用AWS的过程中，个人感觉比较行之有效的方法是以实例（虚拟机）为最小单位，来执行交付。整个的交付理念与容器技术不谋而合。如图：
如图可以看到，整个持续集成部分是以神器Jenkins为核心执行部署，并加上单元测试、冒烟测试、自动化测试等，来实现集成环节的自动化。（测试的部分后期看完书再补充）
在上图中，另外一个核心的部分就是持续交付。对于传统运维来说，对于所有的变更操作都是排斥的，因为变更就意味着要改变稳定的运行状况。而每次的产品交付，就是一次重量级的变更，严重的甚至会造成整个环境的崩溃。在AWS上，我们使用镜像来作为交付的最小单位，最大的好处就是可以保证各个环境中服务器信息的一致性，减少由于环境变化所带来的不稳定因素。而且通过调用AWS的服务接口，可以将这一过程完全实现自动化。这就意味着在整个交付的过程中，操作人员（不一定是运维人员）仅仅需要花几秒钟点击几下按钮，后面的操作会由程序自动执行，并将执行结果反馈回来。而自动化带来的好处就是整个交付的过程可以多次且反复的进行尝试，不用担心时间上的开销。另外需要注意的一点就是，环境的不同相应的也会带来一些配置参数或文件的不同，这就需要通过CMDB来对环境的配置信息进行管理。
特征3：自动化的监控平台
监控简单的可以被分为系统监控和业务监控。目前有很多的开源监控工具可供使用，而很多云服务厂商也都会提供一定的监控服务。所以在指标的监控上面并不会存在多大的问题，难点在于如何实现自动化的应急响应和处置。所幸，大多数云平台都会提供服务器扩容服务来应对临时的突发流量；针对故障，云厂商也都会有开放的接口让用户可以去自定义应急处置行为。
通过简单的扩容、缩容、重启、替换故障服务器，可以有效的解决大部分的应急响应事件。这里要强调的一点是，没有人可以预测到所有尚未发生过得事情，当一个事件反复发生，或无法被有效的自动修复时，还是需要人工干预进行故障的定位和排除。我们基于AWS搭建的自动化监控平台，由于采用简单粗暴的重启、替换服务器的故障处理方式，一定程度上可以覆盖某些未知的故障，但对于无法修复的故障会进行记录，这样在下一次故障发生时，就可以有效的进行响应。
另外要说的就是前文提到的需求的收集和反馈。运维手里掌握着大量的IT运营数据：QPS、延迟、服务器信息、用户行为数据等。如何将这些数据归纳、整理，并且与产品、研发、测试、运营等部门建立有效的反馈机制，为公司运营和产品的优化提供数据支撑，是DevOps中运维所承担的另一个重要职责。
特征4：建立有效的反馈回路
在一个流程每个关键节点都建立起反馈机制，并将反馈及时通知到相关人员，相关人员根据反馈信息采取对应的措施，并再一次尝试去完成流程，形成一个完整的闭环，称之为反馈回路。
就像刚刚有提到运维手中的数据可以为公司运营提供有力支撑，实际上在所有IT自动化的各个流程节点都应该建立相应的反馈回路，将各节点的当前和历史状态展现给所有相关人员，使得整个流程的透明性，可以有效的提高工作效率。甚至，在初创型公司，因为组织架构相对要简单很多，可以尝试在所有部门之间都建立反馈回路，一是可以提高公司员工的工作效率；二是遇到问题可以集思广益；三是可以大大增强员工的参与感。
特征5：全生命周期的资产管理
使用云计算平台的一大优势就是灵活。云端的资源对于一家初创型企业来说，几乎是无穷无尽的。IT部门可以通过少量的资金，在短时间内获得大量的资源，来做数据处理、测试等工作。在使用云平台的资源时，我的经验是有需要就用，不用就及时停止。目前大部分的云平台都提供按需计费的方式，计费力度从秒到小时不等。随着产品需求的增长和业务规模的扩大，研发和测试团队在某一个周期内不可避免的会对资源有更多的需求，不出意外的会向运维索要资源。如果这种索要变得很频繁，运维人员就会疲于应付，自动化的资源管理就显得尤为重要。我在运维工作中有一个原则，所有一个月内操作会超过两次的事情，我就会把这项工作加入需要实现自动化的工作列表中。
在基于AWS接口开发的自动化运维平台上，研发和测试团队的员工可以很方便的通过自动化平台申请所需要的资源，并且从指定的配置列表中获得初始的环境配置。这样可以大大减少运维人员的工作量，同时也有效提高了研发和测试的工作效率。为了防止对服务器的滥用，需要遵循谁申请，谁负责的原则，并对所使用的资源按照云平台提供的价格进行计费，这样可以实现非常有效的成本管控。通过对资源实行灵活自助且落实到人的自动化管理，公司在业务快速增长的同时，成本却以每年节省13%的趋势在下降。而对于初创型公司来说，IT成本的节约，意味着可以将有限的资金更多的聚焦在业务的拓展上，为企业赢得发展的空间。
特征6：信息安全审计
关于信息安全，这里也简单的聊一些心得。接触过ITIL的同学应该都知道，ITIL之所以要求对所有变更做严格的记录和审查，是为了发生问题后更容易进行回溯。其实很多大神都已经提出过这样一个概念，DevOps提出的自动化一切的思路，与ITIL的理念是吻合的。因为人是会犯错的，而且错误会千奇百怪，可是自动化的程序是不会犯错的，因为所有的操作都早已在程序中设定好。在一定程度上，代码的层面的东西更容易进行合规性和安全性审查。
初创企业的DevOps实现路径
01运维可以在IT架构设计的初期及早的介入，提出自己的运维需求
要想实现自动化的运维，无状态的服务器设置、松耦合的IT架构、以及对于业务的关键性指标监控，都是需要在研发阶段早期就需要确定好的。这样才能便于后期的运维工作的开展。
02运维有机会全程参与需求的评审
一个项目是否能够实现敏捷开发，个人认为在项目需求评审阶段就已经决定了。每次迭代的需求不能过重，过重就会导致研发节点难以被拆分，进而影响整个产品的交付周期。真正的敏捷开发需要细化产品需求，做到小而快，才能实现高效的产品迭代。
03利用所有能利用的互联网资源
开源项目就不用说了，免费、好用是共识，而且初创型公司也没有太多的采购要求，能用则用。另外还有很多互联网服务厂商都会提供有限额的免费服务，一般情况下在这些限额内的服务对于初创型公司是足够的。依托这些免费服务，可以建立安全防护、多维度监控、故障溯源等各种能力，为网站保驾护航。
04从零开始，可以最大程度的确保整个IT架构的标准化
经常在和传统行业的运维朋友聊天时，听到抱怨由于各种历史原因，导致无法有效的推进基础架构标准化，而标准化又恰恰是实现自动化的一个重要的先决条件，其重要性毋庸置疑。对于初创型企业来说，应该在一开始就建立统一的IT标准，不要把“历史原因”留给以后的自己。
05建立看板文化，更有效的协同工作
看板文化其实是反馈回路的一个具体时间。因为初创型公司的员工开始都不会很多，场地也不会很大，那么在一个显眼的地方放置一块白板，大家可以在其上写上自己的工作进度或是对公司的建议，这是一个非常有效的沟通手段。有些公司喜欢使用Confluence工具来做记录，个人觉得Confluence更适合做知识的分享。在实际使用过程中，感觉还是一块白板来得方便且直观。
06公司整体架构的扁平化 可以减少层级沟通所需要的时间，从上到下更容易达成思维的一致，建立起DevOps的企业文化。大型的企业在推进DevOps的时候，因为一些权责关系，或多或少会遇到一些阻碍，而初创型公司的组织架构都会相对扁平，关系会比较单纯。如果在一开始就能达成上下一致，共同建立起DevOps的企业文化，无疑会对将来工作的开展起到很大的帮助。
原创：云竹
页:
[1]