优维匡云竹：初创型企业的DevOps之路_云资讯

W020170419583558760819

匡云竹：大家下午好。我今天分享的主题是一个初创型企业的DevOps之路，之所以想借这个机会跟大家做一些分享，我个人认为创业型公司跟DevOps是天然的相辅相成的关系，首先一个初创型企业本身的组织架构，还有它的IT建设，其实是特别益于DevOps的生存和创建。DevOps本身的特性也特别符合创业型公司的需求。

我要匡云竹，以前是在一家央企工作，后来自己出来创业。先后经历了两家互联网创业公司，都是在互联网金融领域，基本都是前面5号的员工都是从零开始。本身的岗位职责就是做运维，帮助企业实现自动化的运维体系建设，现在在优维科技。

先简单提一提我对创业的看法或者一些想法。首先创业，大家开始做创业的时候大致有一个方向，我要做一个什么样的事情，但是对于这个事情到底做成什么样子，具体做出来会是什么效果，大部分人的心底都是没有底气的。为什么没有底，你在做这样一件事情的时候，可能用户的需求不那么明确，也不那么确定。我们在创业的前期需要大量的实践或者探索，去寻找用户的需求在哪。好的来源是在用户，让用户成为你的需求提出方，这样你做出来的产品才会有一些明确的市场需求。另外是产品的响应程度，公司到底能够有多快的速度去实现产品的迭代，比如你的用户需求收集上来之后，你能多快时间内把它收集上来。

再谈一谈初创型企业的核心能力是什么，我个人认为他的一个核心能力就是生存，一切都以生存为目标，你只有先活下来才有往下面走的可能，才能继续去做一些更有意义的事情。如何去生存，首先创业公司需要有一个有竞争里的产品，去为公司创建一个可以生存的空间，给你业务提供一个稳定运行的环境，保持你的用户黏性，抓住你的用户，你就可以慢慢探索企业的战略目标到底在哪。

说了那么多创业的事情，DevOps跟创业到底有什么样的联系，在创业公司核心的一个生存能力或者核心的竞争能力，就是你的产品，你要设计或者你要交付出来一个有价值的产品才能实现你企业本身的价值，我们通过不断的去完善我们的产品，去不断的交付出我们的产品，DevOps其实就是去帮助我们的企业不断的实现快速的交付，打造我们有价值的产品。

具体怎么做，要分三步走，第一步，打好一个基础，第一点要有一个IT资源的标准化。另外是运维的需求，运维也需要根据我们对产品的一些理解提出运维的一些需求出来。首先来看看标准化，我个人认为标准化其实是实现自动化先决的一个条件，要是你企业的基础架构资源没有实现标准化，你想要把它实现自动化，你可能就要考虑N多种产品，要做到自动化其实非常困难。在创业公司，在一个IT设计或者IT规划的前期，我们就去把各种各样的标准化定义好，比如我们采用什么样的服务器，采用什么样的操作系统，它的环境变量和配置怎么样。我们应该采用怎么样的应用容器，应用包的存放路径应该放在哪个目录下，应该在最初期的阶段把这些东西都提前定义好。我在云端的实践，我会创建一个初始化的镜像，这个镜像会基于一些标准化的配置，比如我的环境变量，需要采用什么样的容器，基于这个镜像去创建我以后所有的各个环境的服务器，所有环境的服务器都是基于一个初始化镜像创建出来，这样可以保证所有环境的服务器的底层配置是一致的。再提一下运维的需求，在一般的传统的运维上，一个角色更多的是一个被动的接收者。比如开发人员那边已经把开发测试完以后，再推到运维这边来，运维其实是被动的接收做一个版本发布的事情，我觉得在DevOps里面，运维的角色应该要前置，前置到产品需求提出的位置，产品经理在召开大家一起讨论产品需求会的时候，运维也要参与，运维需要根据产品的一些特性，去提出自己的一些需求。比如说这里提了三个需求，松耦合、无状态、数据收集。这样做的一个好处是，我们可以在我们后期的生产环境的运维里，我们可以实现动态的扩容或者缩容，因为我们如果使用云端服务器的话，我们要设计出我们的架构，要能够保证我的服务器可以随时增加可以缩减的。如果这个时候没有做好松耦合和无状态两个先决条件，那么这些功能都没有办法实现。我们当时在云端做的是，通过扩展组服务实现服务器动态的横向扩容，我们会把所有的带状态的文件，一些用户存放的文件，都会存放到一个对象存储的服务器，也就是AWS的S3的那个服务上。所有的用户的缓存信息，我们都会放在缓存服务器上。再说一下数据收集，数据收集其实是我在两家创业公司都没有做得太好的事情，因为我们在前期并没有考虑去收集更多的用户数据，一个是考虑成本因素，另外一个也没有这样的概念去做这样的事情，导致我们后期需要去做一些BI系统，需要去根据我们的一些用户行为做一些分析的时候，发现我们浪费了很多的用户数据，造成很大的浪费。当我们有一个比较扎实的基础，我们就可以基于这样的基础，就像盖楼一样，我们先有一个地基，我们把地基打扎实了，才可以在上面实现一些比较炫的设计和实现。当我们有了一个扎实的IT基础架构，我们就可以尝试去探索一些公司的发展方向，去寻找我们用户的需求到底在哪里，因为整个市场现今来看，特别是在互联网的环境里，市场是随时都在变化的，它的用户或者是用户的需求也是不停在变化。IT这边对于去探索用户需求，我们可以通过快速迭代产品的能力，去帮助我们的产品或者我们公司探索用户需求，不断去试错，主要从自动化的能力，我们可以实现自动化的打包、编译、测试，实现自动化交付的能力，再强调一下沟通协作，就可以帮助公司快速的迭代产品。这是一个简单的自动化部署的示意图，简单说一下流程。首先是当一个开发者提交了一段代码，说我完成了一个功能，然后把代码提交到代码库以后，自动化这边会自动出发、打包、编译、部署、自动化测试，测试通过以后会自动交付到对应的环境上去。当时我们在AWS的S3上的云端实践，我们通过Jenkins来做一个持续集成，通过一个镜像来做一个版本或者应用的交付。通过镜像的交付其实可以保证就像Docker的容器技术一样，可以保证系统资源的一致性。当我们通过快速的产品迭代，不断去实现，去探索用户的需求，当我们的方向明确以后，我们就可以讲究一些高效的做事方法，大步流星或者小步快跑的去往我们企业的价值方向去出发。可以从四个方面来看，通过自动化来高效工作，通过看板文化来实现协作，通过一个轻量级的ITSM来实现高效流程的运转，再通过一些资源的控制和管理来实现我们有效的资源利用。

首先自动化一切，在做自动化的时候我个人有个观点，不要一开始把你的自动化想得又大而全，是说基于DevOps它里面有一个JKK的原则，这个JKK是一个日文词组的缩写，我也是在上萧老师的DevOps Master的课程的时候了解到这个词。主要的核心理念是你要在正确的时间去做正确的事情，不要提前去做一些你将来可能会用的但实际上不一定会用到的功能。放到自动化来说，我们在日常工作中，我们会把各种工作，把最常用的优先实现它的自动化，实现以后，我们在日后过程中慢慢去积累，慢慢去扩展，这个自动化实现的方式可以是脚本，也可以是工具，都无所谓。当你觉得后期你去管理大量的脚本和工具的时候，你会觉得很困难的时候，这个时候你才去考虑说我把所有的工具和脚本放在一个统一的运维管理平台上来做统一的管理。我们在云端的实践，基本上所有的公有云都会提供一个开放的API，你所有的云平台的一些功能，你都可以通过API来实现。我们基于云平台的API可以实现环境创建，这个环境的创建是我们把所有的基础资源都当成一段代码来管理，我需要创建一个新的环境或者创建一些新的资源的时候，我只需要对这些代码中的参数做一些小的修改。第二点是我们可以通过云平台去实现一个资源的自动申请，比如说研发和测试，他如果需要资源来提高他的一些工作效率，因为云端所有的服务都是一个基于按需收费的原则，你用多长时间收多长时间的钱，而且普遍都还比较便宜。版本发布和故障自愈还有监控这些东西，基本上都是运维工作中的几个核心工作之一，一般都是要优先去实现的。另外是看板文化，在我们日常生活中它更多的会用在一个项目管理的角色里去。它的目的是为了建立高效的信息沟通渠道，但是其实以我个人的看法来说，首先看板的方式是不限的，不管是通过一个白板或者工具，其实都是无所谓的，看板的目的是来提高我们沟通协作的效率，实现的方式其实无所谓，只要大家能接受，会去使用就ok。这跟内容可以多说一点，一般的看板都是用来做项目管理去提高IT内部各个部门的工作效率，我个人认为在创业型公司看板还可以做成另外一个，可以上升到一个企业的高度，所有的员工都可以发挥更多的光和热。我们可以建立一个以企业为高度的看板，所有的人都可以在这个看板上去提出自己对需求的一些想法、对产品的一些想法，或者对企业发展方向的想法。通过一个看板来建立一个企业内部的高效的沟通和协作，效果比仅仅使用在部门内部会更好。

再说一下轻量级的ITSM，因为DevOps一直在强调我要一个敏捷，并不是说我强调敏捷就抛弃流程，就像我们以前的一个实践，说一个例子，当时场景刚上线的时候已经实现了自动化的部署流水线，大家用起来都很爽，但是我们有一天发了单一一个应用发了20多次版本，基本上一天24小时，你可能不到1小时就要发一个版本。具体的原因就是因为我们没有通过我们的部署流水线去实现我们快速的交付有价值的产品、高质量的产品，我们通过这样的一个自动化的流水线，不断输出有Bug的产品，这是因为我们缺乏对流程的控制，研发人员对代码不负责任，测试那边覆盖率没有达到标准，导致我们整个产品不断的去发现Bug、修改Bug，后来也是痛定思痛，加入了一些流程的管理，比如说我会要求研发他在提交找测试的时候，他的一个输出条件是说我一定要通过我自测的测试，必须要保证我的代码是打包编译，并且可以run起来的。做到后面的自动化是跟我们的ITSM平台做一个对接，当研发那边提出说要修改数据的时候，我们做一个镜像拉出来，在这个镜像底下去跑这个脚本，跑完以后把这个结果是成功还是失败，还有匹配的函数，都直接返回到ITSM里面去，然后再交由上层去做审查，如果审查通过或者审批通过，自动在生产把这个脚本跑完。这样整个流程中运维其实就没什么工作在里面。

再说一说关于资源使用的案例，比如说资源我们可以简单分为人力浪费、基础资源浪费还有资金浪费，就像刚刚说的云端的资源，有很多都是便宜而且是很灵活的可以使用的，如果可以提高研发测试人员的构成效率，不要去限制他们的使用，应该放开让他们去用。但是这个地方又有一个坑，如果完全放开给研发和测试的人员用，他们的脑袋里是没有维护的概念的，他们会很不负责任的去使用这个责任。如果全给他们去搞，到最后你就会发现，你的一个环境里可能有一千多台服务器，你自己都搞不懂哪台服务器干什么用的，承载的业务是什么，到底是生产的还是测试的，会造成一个这样的后果。运维这边如何去管理这样一个事情而又不需降低他们的工作效率，可以把这样的一个入口统一的收到一个自动化管理运维平台来，只有通过这个平台研发和测试才可以去申请资源。通过这样的平台，我们就可以去了解哪些人在哪些时间申请怎么样的资源，甚至我们可以给这些资源做一个计费，我们就可以做一个很好的资源的管理，并且去督促研发和测试人员他们不要去浪费一些资源，因为我们会有记录的，你要浪费了都会知道的。

通过建立一个良好的基础，找到一个很好的企业发展的方向或者明确的方向，通过小步快跑去快速实现我们企业的价值，整个DevOps所实现的额企业价值的创造点就在这个地方。