IT名词

1、QPS

每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间。 

公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 。

机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器 。

每天300w PV 的在单台机器上，这台机器需要多少QPS？ 

( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)。

一般需要达到139QPS，因为是峰值。

QPS 

每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

每秒查询率

因特网上，经常用每秒查询率来衡量域名系统服务器的机器的性能，其即为QPS。

对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。

 

DEVOPS

随着业务复杂化和人员的增加，开发人员和运维人员逐渐演化成两个独立的部门，他们工作地点分离，工具链不同，业务目标也有差异，这使得他们之间出现一条鸿沟。而发布软件就是将一个软件想从鸿沟的这边送去那边，这之中困难重重。

另一方面，行业竞争更加激烈，无论是客户还是公司自身，都要求软件能快速发布，频繁修改，而上边所说的这种隔阂，阻碍了开发团队的生产力，成了企业亟待解决的难题。

 

面对种种突出的矛盾，故事的情节，似乎又回到了当初只有程序员，而没有更细分为开发、测试和运维岗位的时候。

 

DevOps一词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。

DevOps是为了填补开发端和运维端之间的信息鸿沟，改善团队之间的协作关系。不过需要澄清的一点是，从开发到运维，中间还有测试环节。DevOps其实包含了三个部分：开发、测试和运维。

换句话说，DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。专家们总结出了下面这个DevOps能力图，良好的闭环可以大大增加整体的产出。

有些人认为DevOps意味着开发人员接管了运营。这只是一部分而不是全部。当我们意识到部分运营需要自动化时候，运维人员需要进行一些自动化开发，开发人员也编写"运维"代码，或两者兼而有之。可怕的是，没有找到在这两种人员之间的整体协作方法，所有的成功团队都是将具有深度开发技能和深度运维技能人协调在一起工作，以创建一个更好的产品。

一、DevOps常用技术

二、DevOps有三种特点与模式

2.1、系统级别的效率考量

这是强调从整个系统的效率性能考量，而不是孤立地从所在工作部门或子系统考量，可以是整合开发人员和IT运维人员的大视角，也可以小如独立的发布者如开发人员和系统管理员。

重点是关注整个业务价值链，开始于业务需求的确认，开发人员的开发构建，然后交付给IT运维，在最后环节，对于客户的软件价值作为一种服务体现出来。

由于强调整体效能，就不要将缺陷推托到下游，不允许因为局部优化而带来整体退化，不能因为细节战术的提高导致整体战略上的退步，如果想提高整个系统的价值，就必须深入全面理解整个系统。

2.2、放大反馈循环

关于创建从右到左反馈循环。如有必要可以不断修正缩短和放大这种反馈循环。能够理解和响应所有的客户包括内部和外部，缩短和放大所有的反馈循环，嵌入我们需要的知识。

2.3、持续的锻炼和学习

这种方式就是创造一种企业文化，培育两件事:不断实验冒险以及从失败中吸取教训。认识到重复和实践是通向掌握的先决条件。

实验和冒险能确保我们持续推动改善，即使这意味着进入我们无法控制的危险地带，我们必须需要掌握帮助我们脱离危险区域的技能。　

第三条道路的结果包括分配改善日常工作的时间，,为冒险创造仪式，奖励团队，并将错误引入系统增加弹性。

三、DevOps的好处

DevOps的一个巨大好处就是可以高效交付，这也正好是它的初衷。与低效组织相比，高效组织的部署频繁200倍，产品投入使用速度快2555倍，服务恢复速度快24倍。在工作内容的时间分配上，低效者要多花22%的时间用在为规划好或者重复工作上，而高效者却可以多花29%的时间用在新的工作上。所以这里的高效不仅仅指公司产出的效率提高，还指员工的工作质量得到提升。

DevOps另外一个好处就是会改善公司组织文化、提高员工的参与感。员工们变得更高效，也更有满足和成就感，对公司更加认同。

 

错误5、DevOps是运维人的救命稻草

DevOps不是运维人的救命稻草！我把DevOps更多理解成软件研发模式的一种变化，从早期的传统软件工程模式到敏捷模式再到DevOps模式，是让软件研发过程越来越柔和更多的角色一次性进入。

在早期的瀑布式软件工程模式下，研发／测试／维护（还不是运维）是独立和隔离的，研发写好代码并自测后交给测试，测试完成后，维护部署上线。再到敏捷模式下，研发和测试深度融合，测试驱动研发。

当随着基于互联网下的业务敏捷性要求越来越高，维护的重要性日益凸显，单纯过去的维护方法论不足以支撑，此时就需要运维的能力提前加入到软件研发过程中，比如说软件的高可用设计（对软硬件的容错性）／服务监控／自动化能力封装等等。
四、错误理解

错误1、DevOps是运维人的救命稻草

DevOps不是运维人的救命稻草！我把DevOps更多理解成软件研发模式的一种变化，从早期的传统软件工程模式到敏捷模式再到DevOps模式，是让软件研发过程越来越柔和更多的角色一次性进入。

在早期的瀑布式软件工程模式下，研发／测试／维护（还不是运维）是独立和隔离的，研发写好代码并自测后交给测试，测试完成后，维护部署上线。再到敏捷模式下，研发和测试深度融合，测试驱动研发。

当随着基于互联网下的业务敏捷性要求越来越高，维护的重要性日益凸显，单纯过去的维护方法论不足以支撑，此时就需要运维的能力提前加入到软件研发过程中，比如说软件的高可用设计（对软硬件的容错性）／服务监控／自动化能力封装等等

错误2、DevOps就是自动化

自动化很重要，但不代表DevOps就等同自动化。自动化是一种技术要求，当你不是全局自动化的时候，它带来的驱动力更是有限的，况且DevOps从来就不是一个技术问题。

因此我建议一定大家把基于用户价值交付流的自动化作为目标，此时能全局思考对运维内部各团队的自动化要求，对研发、对测试的自动化要求等等。