运维还是运维开发

产出的价值无非2点(无论是小事还是大事，有价值的事情，就必须要去做，方法和工具都是灵活的。
1.节约成本。
2.724小时保证业务不间断运行。

1）成本预算必须要做，否则当业务收支平稳的时候，boss就非常关心了:
1.机器配置统一化,业务也知道配置的选择，而不是迷茫，狮子大开口。
2.业务人数评估(正常量和突发量)
3.各业务产品功能和逻辑梳理，包括使用场景。前期怎么做，后期扩展的方案有哪些？slb-web-cache-db-storage等
4.机器性能对比，包括整体使用率和可用率，否则拿来指标让开发信服
5.对于某些业务，繁多但是使用率居多，可不可以考虑复用？复用的隔离，优缺点在哪，事先要考虑好
6.资产收集库:互联网公司无论大还是小，都应该有自己的独立资产库，虽说这准确率不能达到100%，但是至少也能给你在服务器成本，还有当前的类型中有个清晰的思路，也方便你以后真正做装机＋dns整合开发的时候用吧。
7.发布:单纯运维60%的工作都浪费到这里，因为每家运维的人数大多数比开发少，但是又不可能堆人吧，这时候能有效的解决发布效率，让开发自由发布，但是权限和安全口子都是由运维把关。

2)保证业务可持续运行，稳定:
1.监控方案，开源，自源，还是组合？业务只要清楚出问题，运维和对应业务线的开发能第一时间知道，哪怕网络抖动一点点，还要考虑好报警狂轰滥炸，怎么做收敛？(运维没有完善的监控和收敛机制，就是瞎子过河)
2.集群调度方案，调度的算法需要和业务开发碰，有可能调度的算法，当前业务无法支持，还有整个调度的链路，具体到某台主机去执行用户处理了，开发可以不知道，但是运维必须要知道，自研，还是开源的工具去做跟踪汇报，自己去衡量。
3.按照业务不同逻辑拆开方案，公司越大，产品功能就越多，业务逻辑需要集中化，但是也要细化，集中化是知道一个大业务包含多少子业务，模块，细化是精确到某个LB，哪些机房，节点，包括监控清晰的命名等等。
4.主机命名规范:主机命名最好按照能简单理解，拆分的方式，因为机器多了，内部dns解析也会派上用场，这时候，还是N多的localhost，你会很头疼。
5.日志集中式管理，日志第一要解决的是格式统一化，有的开发输出字符串，有的json，有的list等，这很头疼，剩下的才去考虑从请求－接收－汇总-集合－存储等过程。
6.突发高峰，自动伸/缩对应配置机器，秒杀，高并发的公司，可能某个推广或者热门的消息，就可能导致pcu增多，而负载均衡，db，服务器抗压的峰值都是有一定瓶颈，这时候自动快速构建机器和服务启动标准，就有很大方便了，但是pcu减少了，又不想浪费成本，这时候，整个调度会根据多方面纬度阀值进行对临时主机的销毁，而且保证服务的稳定性。
7.事故降级，切换方案，事故的经验如果没有的公司，可以慢慢积累，并且可以内部把故障设为多个等级，每个等级处理和上报的层级对象有哪些，S级别的故障，比如机房瘫痪了，被***了，备用机房或者多机房扩容和切换？
8.安全预知和防护的方案，除了系统基础的防护，还有最前端的调度可以让外部访问到，一切只允许内部互相调用，而且还要考虑防止误调用，业务故障现象，防火墙还是安全组的规则定义这就需要好好划分和管理了，一定是集中式的，否则太痛苦维护了。
9.新技术选型优缺点衡量，做开发还是运维，如果不能与时俱进，早晚被淘汰，但是一切皆为稳定的情况下进行研究，测试，最后观察没问题，才能替换新技术方案。
10.团队配合，沟通，简单的说明：你说的话，无论运维，开发都能知道你想要干嘛，而且需要他们做些啥，而不是互相扯皮，糊里糊涂的。

本文摘自师兄符哥，供自己收藏

转载于:https://blog.51cto.com/10309478/2068868