高并发是服务器架构的事情,不是单单一台服务器的事情。该花钱的地方一定要花,可以省钱的地方要知道怎么省钱。
21. 运维信息
运维所有信息两个人共享,包括密码和服务器配置步骤,由运维经理带领团队,打造成一个互相学习,技术实力雄厚,目标一致的和谐团队。让每个人在团队中都得到自己想要的。
运维经理的为人就很重要,要不然留不住人,大家心不往一起使劲。运维工作技术不是最重要的,因为这个职位现学现用也来得及,所以工作态度/为人和经验是最重要的。
22. 服务器日志
对服务器建立日志,所有服务器的所有操作都要有记录,并且写清时间操作内容。对生产服务器操作之前一定要做风险评估及解决方案。
23. 运维工作
应用上线后,运维工作才刚开始,具体工作可能包括:升级版本上线工作、服务监控、应用状态统计、日常服务状态巡检、突发故障处理、服务日常变更调整、集群管理、能评估优化、管理优化、随着应用PV增减进行应用架构的伸缩、安全、运维开发工作。
核心运维管理工具箱
重点介绍运维流程管理、运维发布变更、运维监控告警三个方面的具体工具,可作为工作日记使用。
第一类:运维流程管理工具
1.发布变更流程管理工具
做为系统接口与其他角色的工作衔接。并提供审批环节控制发布变更的风险。流程管理工具并不负责具体的业务操作的执行,只是作为单据系统跟踪流程和确保闭环。
2.告警和突发管理工具
体现业务受损的告警自动建单管理。人工确认之后升级为突发单。通过建单管理告警和突发确保流程的闭环,以及每次故障都能够总结出经验,并未度量业务的可用性提供KPI。
第二类:运维发布变更工具
1.版本管理工具()

所有的发布应该以版本管理为起点。研发给的版本包先入版本管理工具,再从版本管理工具分发到现网发布。杜绝 rsync 一台服务器发布另外一台的做法。
2.配置管理工具()
版本加配置等于现网每台机器的状态。最粗粒度的配置管理是到 IP 级别,相当于对机器做资产管理,分组到不同的业务,模块和大区等业务概念上。细粒度一点会管理到进程以及进程的相关配置。
3.配置和版本下发工具
把指定的版本,结合配置好的配置下发到现网的机器上。不同的版本和配置方式需要完全不同的下发方式。以 ssh/fabric 为代表的下发方式是以脚本为中心的。以 puppet/chef 为代表的下发方式是以配置为中心的。
4.现网状态同步工具
为了规避现网状态漂移,与管理工具内的记录不一致。需要有一个工具定时上报现网的实际状况。
5.服务调度工具
发布变更经常需要一个串行的流程,先做A模块,再做B模块。很多机器的时候,需要把能并发的操作并发执行,不能并发的操作确保串行执行。同时很多发布变更流程需要操作管理范围外的服务,比如云端的DNS服务器记录等。这就需要有一个服务调度工具统一调度配置和版本下发工具,流程单据工具,以及其他系统的API接口共同组装成一个流程。
6.资源管理和隔离工具
以xen/kvm为代表的工具让运维可以更灵活的切割资源。比如虚拟机的快速起停,ip在idc内的漂移等。以 lxc/docker 为代表的工具让运维可以进一步的切割资源到进程级别。资源隔离代理的细粒度的资源控制可以获得更好的资源利用率,以及更容易进行可伸缩的资源配置。
7.发布变更统一界面
包装所有的下层工具,提供简单的界面完成标准化的发布变更操作。
第三类:运维监控告警工具
1.采集工具
一般是采集日志文件,也可以是定时轮询 DB 或者其他系统的接口。流行的开源方案是 logstash。
2.收集工具
采集工具上报给收集工具。或者由开发直接修改代码上报指标给收集工具。流程的开源方案还是 logstash。
本文来自电脑杂谈,转载请注明本文网址:
http://www.pc-fly.com/a/ruanjian/article-87549-4.html
给生的希望
写几亿个字儿也是毫无价值的