设计 DevOps 原则

电玩女神 2022-04-03 13:25 154阅读 0赞

企业的组织形态和经济形态决定了 DevOps 的方案。

到今天为止，实习了四个多月了。粗略了解了下 DevOps的概念，简单记录下。

当我们还在学校写项目的时候，由于项目规模较小，基本都自己一个人写完代码，自己测试，测试功能没有问题之后，自己部署项目到服务器，结束！

后来，到公司工作了，项目越来越大，一个淘宝需要几千甚至上万人在开发，一个人的力量毕竟是有限的，就会有一个大团队在一起开发项目。这么多人工作于一个项目，没有明确的分工肯定是不行的，为了达到高效率的工作，工作职能出现了细化，需求-----开发----测试-----运维，每个阶段都有专属的人去做，大家各不相干。于是传统的瀑布模型也就是这样的，最上面的BOSS 安排好开发方案，交给开发人员，经过若干时间，开发完了交由测试人员去做测试，又经过若干时间，不幸的话，会测出一堆BUG，然后再给开发人员去修复，修复完了再测，反反复复，直至最后测试通过，交由运维人员部署项目，上线，给广大用户使用。

这样最大的缺点就是每个阶段所需要的周期太长了，得到反馈的时间也太久了，造成整体开发效率低下，很不友好。后来出现了敏捷开发模式，大意就是把需求--开发--测试绑在一起，大家一块工作，需求发出一部分，就先开发一部分，开发好了，直接交由测试，这样一个一个小功能，小的模块测试，得到反馈的速度提高了很多倍，整个项目的优化是迭代式的，一步一步在改善，开发的效率无形中提高了很多，大家都很开心。

时间久了，敏捷开发虽然把 需求--开发--测试 糅合到了一起，但是和运维人员之间还有一堵墙存在，开发人员和运维人员的目标是不一样的，开发想的是多改变代码，多修正问题；而运维人员追求的是稳定性，尽可能的小改动。每次改动一个版本再去上线需要很多配置步骤，变动太大，每次部署也很麻烦，运维人员不开心，项目部署失败，大家都不好过。

这时候，就出现了一种新的模式，也就是DevOps, 开发人员和运维人员的简写。可以看做在敏捷开发的基础之上，再把运维人员也糅合进来，每次一个小功能的测试完成，就立即上线，最大的好处就是可以极速的得到用户的反馈，然后把修改意见传给开发人员，进行再次修改，测试，上线。这样一来，一个项目可能在一天之内上线好多次，每次改动也不会太大，运维人员也舒服了，最大的好处在于得到用户的反馈速度提高了N倍！！ 这些反馈无疑是非常重要的，有了用户的体验反馈，我们可以更快的做出相应的改变，以满足用户体验感，在这个互联网时代，高效，快速是非常非常重要的。