近期被线上系统运营搞得焦头烂额，究其原因，是因为没有对运维工作作出足够的重视，结果在越南的运营中持续出现事故，不论是人为事故还是越南本身网络环境差导致的问题。 在公司产品做大并且做成熟以后，服务的可用率更加重要，需要通过运维和程序上若干手段去保证，谈谈笔者面临的问题及一些思考
先罗列出问题
事故原因
- nginx配置错误
- 域名解析配置错误
- 证书配置错误
- 网络被切断
- 机器被重启
- 服务单点
- 服务器带宽没有按照要求配置
- ffmpeg运行错误后没有及时拉起
- 磁盘满
- 内存满
- 带宽满
- 机房外网被切断
- 机房内部网络异常
- 等等
事故出现了很多次，部分事故提出明确整改方案，但大部分的事故仍然缺乏总结和改进的有效手段。因为缺乏必要的运维工具及监控统计手段，理想情况下所有的事故都可以通过测试手段、监控手段能及时感知到，配合合适的调度等运维工具，可以快速的解决事故点恢复系统运营
理想下的系统运营包含以下几个手段和方案
-
发布系统
发布系统是系统稳定运行的基础，不能只依靠人去做服务器发布，尽量使用可靠和有效的手段来自动化持续集成和进行发布，目前开源的合适方案为Jekins + ansible playbook -
进程目录树
将服务器运行的进程有效的管理，对服务器和程序进行有效的分类，和发布系统进行配合，并且在系统监控和告警上，能够更加有针对性 -
系统标准化
或许会奇怪为什么会提出这点，主要原因是差异化的系统，给扩容、监控带来了非常多的问题，如网卡名出现了较多的p1p1/p1p2/p2p1/p2p2/em1/eth1等，使用网卡流量监控时，除非对每个网卡进行上报，但上报以后需要进行合适的汇总，监控视图上的差异也会非常大，视图查看时需要逐个输入网卡名。系统标准化也是目前docker大行其道的原因 -
系统级监控
包括但并不限于对服务器的系统属性进行监控和告警，包括cpu、网卡、出入带宽、包量、tcp/udp链接情况、内存和磁盘使用率，这些属于系统基础性监控，如果系统出现瓶颈，最先就会出现及时的告警，并且通过查看视图能够进行快速定位。目前越南运维过程中，就严重缺乏这点，出现问题后，只能通过被动反馈后，逐个登陆服务器进行筛查，而缺乏视图和基础告警快速定位。该系统级监控开源的实现方案为Open-Falcon，或者通过Jekins和snmp自行实现（open-falcon有若干bug，需要进行修改） -
应用程序监控
应用程序监控需要增加及时，当新的程序发布时，系统视图需要及时进行展示。事故经常在新发布代码的时候出现，如果缺乏对新功能的有效监控，无法及时感知问题发生，也就无法及时对程序进行回滚。目前有较多公司采用开源的influxdb + grafana的方案，但influxdb属于时间序列数据库，一般程序还是跑log后写入，缺乏及时性，并且grafana的视图及告警需要进行配置，较为麻烦和复杂，建议采用open-falcon的方案 - 脚本管理系统
脚本管理系统可以和发布系统、进程目录树配合使用，该系统的必要性存在于对服务进行脚本运算，服务监控、拉起、定期删除、日志压缩等任务，如果运维或者程序员自行管理脚本，代价和复杂度较高，使用系统管理起来较为有必要。一般来说，成熟的系统，都需要有以下一些脚本- 发布脚本
- 进程拉起脚本
- 日志压缩脚本
- 删除文件脚本
- 定期事物运行脚本
- 告警脚本
- 机器重启拉起脚本
- 其他
- 调度系统
有较多的公司在初创时没有该系统，该系统主要目的是实现网络异常或服务器异常的调度，为了分布式计算或运维而实现，必要性毋庸置疑。目前较多的实现可以是zookeeper，或者是按照ack数据包做简单的hash一致性实现。但服务器的可用性、机器的可用性和服务器的负载均衡，其实都可以用该系统进行实现。我们也踩过若干次此坑，但因为公司没有成熟的调度系统，机器故障等大部分还是依靠运维的手工介入~~~原始
结束
暂时就想到了这些，因为缺乏，才凸显的更加重要和必要，在公司规模和用户量小的情况下，部分系统没有必要，但是一旦上了规模，可能会发生的事故一定会发生，因为大规模并发会放大事故出现概率
公司快上市了，可这些东西都非常欠缺，只能说这个公司是一个合格的商业公司，却不是合格的技术公司，在缺乏充分竞争的情况下商业运作是ok的，但如果竞争激烈，技术的短板也会体验，从而影响公司的整体情况。