我们的运维理念是：Ops Make No Ops，希望把运维的日常工作尽可能的自动化起来，减少手工运维操作。做为一个运维人员，没有人愿意每天重复那些繁琐的运维操作；更没有人愿意每天处于高度紧张的精神状态，随时准备应对线上故障。

我们的目标是打造一个技术型、学习型的团队，通过新技术的研究，学习分享提升整个团队的技术影响力，使我们的运维工作更加高效。提供类似SaaS、DaaS、PaaS、IaaS的服务，一层层的向上封装。最终使研发人员能够在运维体系的架构下自助的进行资源申请、服务部署、运行监控和容灾备份，提供稳定、高效和安全的互联网服务。使我们的运维人员能有更多的精力参与到运维自动化体系的建设中，能有更多的精力投入到业务架构设计和性能优化中。

研发能力

做为运维人员，首要的任务是保证服务稳定高效的运行，7*24为用户提供互联网服务。由于互联网业务的特点，往往是研发周期短、功能不断迭代、文档不全、规模发展快速。那么对于运维人员在技能方面就有很高的要求，除过操作系统、网络、硬件、开源软件应用等基础要求外，还需要强调运维人员的研发能力。

一方面，运维人员具备研发能力可以快速上手研发人员交付的线上服务。充分理解程序的功能逻辑，才能提前发现隐患，给出合理的运维建议。在优化方面才能有的放矢，而不是查找网上资料，按照前人经验不断的调“试”。我们甚至希望每位运维工程都是产品架构师，能够对业务服务的系统架构进行合理性规划和改进。

另一方面，运维人员具备研发能力也能更直接有效的把运维经验形成工具和平台，更有效的推进服务运维的自动化。在运维人员，特别是应用运维人员招聘中，我们更关注是否具备研发能力。国内很多从事互联网运维的人员在研发能力方面都相对薄弱，大多属于操作维护类。所以在某国内大型互联网公司中，运维部中校招人员占比90%，招聘最基本的要求就是具备研发能力、掌握至少一种脚本语言，熟悉数据结构。另外做为运维人员，除了考虑研发能力和知识全面性之外，我们还会重点关注动手能力。

和一些公司的运维团队不同，我们虽然也有运维平台研发团队，但更多的工具和平台研发工作是由运维人员负责。专职的平台研发人员很多没有接触过运维，不清楚运维人员真正的需求和痛点，通用的平台不能满足所有运维人员的需求，专项的平台又很难在需求功能上达到平衡。以前经常遇到平台研发和运维相互指责的情况，平台研发认为运维不配合他们的工作，运维认为平台研发不懂运维需求。

我们的平台研发团队主要负责最基础的核心功能和UI研发，运维人员参与需求收集和设计评审，比如服务管理平台的服务树和权限的需求讨论和模型设计。而运维人员负责监控系统、部署系统、环境初始化以及各种的日常运维工具的研发。拿部署系统举例，运维人员负责了build模块、客户端、控制端的研发工作，平台研发人员负责Web界面的研发。

平台研发理念

如运维平台章节介绍的那样，我们在运维平台的设计中，提供各种API接口给运维或研发人员使用，他们根据自己的运维场景封装成个性化的工具或平台。以前涉及到服务器装机、改名、重启等操作都需要系统工程师负责，应用运维工程师发单让系统工程师操作。系统工程师将这部分工作形成自动化，提供API给服务管理平台。服务管理平台基于服务树和权限模型，提供给应用运维工程师使用，应用运维工程师能够对有权限的服务器进行一系列基础操作。渐渐的应用运维工程师将这部分权限开放给研发人员，研发人员也可以使用。同理，对于服务器资源申请、模块部署、监控添加都交给研发人员去使用。

运维人员除了平台研发和维护外，能够将精力放到其他更重要的事情上，避免了繁琐的沟通，工作效率也提升了。Hadoop研发人员使用资产信息提供的API，服务器的分布、交换机的参数、机柜的分布，能够更方便的调度和决策数据如何存储，避免由于机柜级别故障导致的服务受损。部署系统使用监控系统提供的API进行运行状态查询和监控项添加，在每台服务器部署前暂停监控，部署完成后启动服务、更新监控，判断监控正常后继续下一台部署工作，做到部署动作与监控状态的联动。

学习与分享

我们需要具备研发能力的优秀运维人员来帮助业务提升稳定性，但优秀的人才都不愿长期从事繁琐的操作类事务，不仅需要给予他们研发项目提升技术能力，也需要给予他们“有趣的事情”，研究新的技术。在工作时间上，尽量给员工买时间、投资源，在不影响业务稳定的前提下，投入20%~40%在项目研发和新技术研究上。

比如Https网站的SSL运算会消耗大量的CPU资源，工程师在经过研究后提出了采用类GPU的方式，用硬件加速卡来进行RSA运算，同时又对Nginx进行代码优化充分发挥硬件加速卡的性能，提升了服务质量还降低了资源成本。这样做的目的不仅能使我们的运维工作越来越出色，还能帮助我们看清未来的方向。比如虚拟化、Docker的研究帮助我们更好的进行服务部署，对大数据的研究帮助我们识别网络4/7层攻击行为。

我们鼓励工程师多学习、多交流，也希望团队是一个开放型的团队，能够把我们遇到的问题，好的经验分享出来，帮助个人、帮助团队、帮助行业共同成长，这也是我们写这本书的目的。

开源软件使用

在开源运维软件方面，我们保持着跟随不盲目的心态。任何一款开源软件，我们必须做到掌握到代码级别的能力，和运维公司内部的产品一样，不仅能很好的使用开源软件，还能够动手分析和解决遇到的问题。不重复造轮子，但对开源软件的使用，也要清楚认识我们使用它的场景。

我们使用了Puppet、Ansible、Zabbix、God、Docker、Mesos、Etcd等等，Puppet在部署工具的第一版，我们仅仅用它的DSL做部署行为的语法解析和执行，并没用到它的客户端和服务端配置管理功能。有服务管理平台提供的服务树和权限模型，不需要再单独维护Puppet的服务器列表。

Ansible主要使用它对服务器进行临时性的批量操作执行。我们每台服务器上已经有一个超级Agent，不希望引入太多有执行逻辑的Agent，所以我们选择使用Ansible和SSHD进行交互。同时，我们改造Ansible和服务树结合，工程师可以使用个人帐号很方便的对有权限的服务器，进行临时批量的任务执行。

Etcd主要用来做LVS的Real Server注册，Real Server上新增Nginx启动后往Etcd注册状态，LVS实时读取列表更新本机的配置文件并Reload。

监控最早也是使用Zabbix，和服务树结合进行监控和报警策略的管理，随后由于开源监控系统无法满足需求，才开始研发自己的监控系统。

小结

最后，真的很痛恨Operator这个称呼，我们目标是提供各种运维自动化平台或工具，让研发自助式的完成产品运行发布所需要的各种动作，No Ops!

（文章来源运维派）

我们的运维理念是：Ops Make No Ops，希望把运维的日常工作尽可能的自动化起来，减少手工运维操作。做为一个运维人员，没有人愿意每天重复那些繁琐的运维操作；更没有人愿意每天处于高度紧张的精神状态，随时准备应对线上故障。

我们的目标是打造一个技术型、学习型的团队，通过新技术的研究，学习分享提升整个团队的技术影响力，使我们的运维工作更加高效。提供类似SaaS、DaaS、PaaS、IaaS的服务，一层层的向上封装。最终使研发人员能够在运维体系的架构下自助的进行资源申请、服务部署、运行监控和容灾备份，提供稳定、高效和安全的互联网服务。使我们的运维人员能有更多的精力参与到运维自动化体系的建设中，能有更多的精力投入到业务架构设计和性能优化中。

研发能力

做为运维人员，首要的任务是保证服务稳定高效的运行，7*24为用户提供互联网服务。由于互联网业务的特点，往往是研发周期短、功能不断迭代、文档不全、规模发展快速。那么对于运维人员在技能方面就有很高的要求，除过操作系统、网络、硬件、开源软件应用等基础要求外，还需要强调运维人员的研发能力。

一方面，运维人员具备研发能力可以快速上手研发人员交付的线上服务。充分理解程序的功能逻辑，才能提前发现隐患，给出合理的运维建议。在优化方面才能有的放矢，而不是查找网上资料，按照前人经验不断的调“试”。我们甚至希望每位运维工程都是产品架构师，能够对业务服务的系统架构进行合理性规划和改进。

另一方面，运维人员具备研发能力也能更直接有效的把运维经验形成工具和平台，更有效的推进服务运维的自动化。在运维人员，特别是应用运维人员招聘中，我们更关注是否具备研发能力。国内很多从事互联网运维的人员在研发能力方面都相对薄弱，大多属于操作维护类。所以在某国内大型互联网公司中，运维部中校招人员占比90%，招聘最基本的要求就是具备研发能力、掌握至少一种脚本语言，熟悉数据结构。另外做为运维人员，除了考虑研发能力和知识全面性之外，我们还会重点关注动手能力。

和一些公司的运维团队不同，我们虽然也有运维平台研发团队，但更多的工具和平台研发工作是由运维人员负责。专职的平台研发人员很多没有接触过运维，不清楚运维人员真正的需求和痛点，通用的平台不能满足所有运维人员的需求，专项的平台又很难在需求功能上达到平衡。以前经常遇到平台研发和运维相互指责的情况，平台研发认为运维不配合他们的工作，运维认为平台研发不懂运维需求。

我们的平台研发团队主要负责最基础的核心功能和UI研发，运维人员参与需求收集和设计评审，比如服务管理平台的服务树和权限的需求讨论和模型设计。而运维人员负责监控系统、部署系统、环境初始化以及各种的日常运维工具的研发。拿部署系统举例，运维人员负责了build模块、客户端、控制端的研发工作，平台研发人员负责Web界面的研发。

平台研发理念

如运维平台章节介绍的那样，我们在运维平台的设计中，提供各种API接口给运维或研发人员使用，他们根据自己的运维场景封装成个性化的工具或平台。以前涉及到服务器装机、改名、重启等操作都需要系统工程师负责，应用运维工程师发单让系统工程师操作。系统工程师将这部分工作形成自动化，提供API给服务管理平台。服务管理平台基于服务树和权限模型，提供给应用运维工程师使用，应用运维工程师能够对有权限的服务器进行一系列基础操作。渐渐的应用运维工程师将这部分权限开放给研发人员，研发人员也可以使用。同理，对于服务器资源申请、模块部署、监控添加都交给研发人员去使用。

运维人员除了平台研发和维护外，能够将精力放到其他更重要的事情上，避免了繁琐的沟通，工作效率也提升了。Hadoop研发人员使用资产信息提供的API，服务器的分布、交换机的参数、机柜的分布，能够更方便的调度和决策数据如何存储，避免由于机柜级别故障导致的服务受损。部署系统使用监控系统提供的API进行运行状态查询和监控项添加，在每台服务器部署前暂停监控，部署完成后启动服务、更新监控，判断监控正常后继续下一台部署工作，做到部署动作与监控状态的联动。

学习与分享

我们需要具备研发能力的优秀运维人员来帮助业务提升稳定性，但优秀的人才都不愿长期从事繁琐的操作类事务，不仅需要给予他们研发项目提升技术能力，也需要给予他们“有趣的事情”，研究新的技术。在工作时间上，尽量给员工买时间、投资源，在不影响业务稳定的前提下，投入20%~40%在项目研发和新技术研究上。

比如Https网站的SSL运算会消耗大量的CPU资源，工程师在经过研究后提出了采用类GPU的方式，用硬件加速卡来进行RSA运算，同时又对Nginx进行代码优化充分发挥硬件加速卡的性能，提升了服务质量还降低了资源成本。这样做的目的不仅能使我们的运维工作越来越出色，还能帮助我们看清未来的方向。比如虚拟化、Docker的研究帮助我们更好的进行服务部署，对大数据的研究帮助我们识别网络4/7层攻击行为。

我们鼓励工程师多学习、多交流，也希望团队是一个开放型的团队，能够把我们遇到的问题，好的经验分享出来，帮助个人、帮助团队、帮助行业共同成长，这也是我们写这本书的目的。

开源软件使用

在开源运维软件方面，我们保持着跟随不盲目的心态。任何一款开源软件，我们必须做到掌握到代码级别的能力，和运维公司内部的产品一样，不仅能很好的使用开源软件，还能够动手分析和解决遇到的问题。不重复造轮子，但对开源软件的使用，也要清楚认识我们使用它的场景。

我们使用了Puppet、Ansible、Zabbix、God、Docker、Mesos、Etcd等等，Puppet在部署工具的第一版，我们仅仅用它的DSL做部署行为的语法解析和执行，并没用到它的客户端和服务端配置管理功能。有服务管理平台提供的服务树和权限模型，不需要再单独维护Puppet的服务器列表。

Ansible主要使用它对服务器进行临时性的批量操作执行。我们每台服务器上已经有一个超级Agent，不希望引入太多有执行逻辑的Agent，所以我们选择使用Ansible和SSHD进行交互。同时，我们改造Ansible和服务树结合，工程师可以使用个人帐号很方便的对有权限的服务器，进行临时批量的任务执行。

Etcd主要用来做LVS的Real Server注册，Real Server上新增Nginx启动后往Etcd注册状态，LVS实时读取列表更新本机的配置文件并Reload。

监控最早也是使用Zabbix，和服务树结合进行监控和报警策略的管理，随后由于开源监控系统无法满足需求，才开始研发自己的监控系统。

小结

最后，真的很痛恨Operator这个称呼，我们目标是提供各种运维自动化平台或工具，让研发自助式的完成产品运行发布所需要的各种动作，No Ops!

（文章来源运维派）