产出的价值无非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.团队配合,沟通,简单的说明:你说的话,无论运维,开发都能知道你想要干嘛,而且需要他们做些啥,而不是互相扯皮,糊里糊涂的。

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