服务器日常运维保障方案

服务器日常运维保障方案我做企业服务器运维快八年了，见过核心服务器凌晨突发宕机导致全业务停摆的慌乱，也经历过提前排查出隐患、悄无声息解决问题的安稳，深深明白服务器就是整个公司业务的心脏，日常运维只要松一寸，后续可能就会出一丈的乱子。为了把我们日常运维工作标准化、精细化，保障所有业务系统稳定持续运行，结合我这些年踩过的坑、积累的经验，整理出这套可落地执行的服务器日常运维保障方案，整体目标就是实现“日常无隐患、故障快响应、业务零感知”，给公司业务发展托好底。1日常分级巡检运维体系巡检是日常运维的第一道防线，很多大故障都是从小异常慢慢发展来的，要是一开始就没发现，拖到最后就是不可挽回的损失。我们把巡检按照频率和深度分成三个等级，不同等级覆盖不同的检查内容，确保没有死角。1.1每日例行巡检每日巡检是每个运维值班人员每天到岗后的第一件事，哪怕我们现在有自动化监控告警，我还是要求大家必须手动过一遍核心指标，不能全依赖系统。具体内容首先是看监控大屏的核心数据，包括所有物理机、云服务器的CPU负载、内存使用率、磁盘剩余空间、出入口带宽这四项基础指标，核心业务服务的进程状态、端口连通性也要挨个确认，其次看前一天的告警记录，有没有遗留的警告没处理，哪怕是不影响业务的小警告，也要标注清楚原因和跟进计划，最后要登记当日的巡检台账，把所有异常情况和处理结果写清楚，我每天下班前都会抽十分钟翻一遍当天的台账，就怕有人漏了细节。我之前就碰到过一次，自动化告警的磁盘阈值设的是90%，那天一块存业务日志的磁盘涨到了87%，系统没告警，但我手动看的时候发现涨速不对，前一周才涨到60%，提前清了半个月的过期日志，没等占满就解决了，要是那天没手动看，再过两天肯定就出问题了。1.2每周深度巡检每周的深度巡检会比每日巡检更进一层，不看表面指标，挖隐藏的问题。首先要批量导出所有服务器的系统日志、应用日志、数据库日志，搜有没有高频报错和警告，比如数据库连接超时、接口调用失败这类错误，哪怕每天只有几次，也要找到源头解决，不能留着；其次是备份验证，我刚做运维那会吃过亏，自动化备份显示成功，真出问题要恢复的时候才发现备份文件损坏，所以现在我们每周都会随机抽一份前一周的全量备份，做一次恢复测试，确认备份可用，这个流程谁都不能省；最后还要做机房现场检查，物理机要摸一下机箱温度，听听风扇有没有异响，看看机房的空调、消防、漏水检测系统正不正常，机架的网线电源线有没有松动，这些硬件问题自动化监控是很难提前发现的。1.3月度全面巡检月度巡检是对所有服务器的一次全面体检，覆盖所有细节，不会放过任何一个角落。内容包括全量漏洞扫描，所有服务器的系统漏洞、应用漏洞都扫一遍，高危漏洞标记出来优先修复，整理权限清单，删掉离职人员的账号、关闭不用的闲置服务和端口，检查所有核心硬盘的SMART健康信息，提前发现硬盘坏道、寿命即将到期的隐患，最后把整个月的巡检情况、异常处理情况整理成正式的月度运维报告，交给技术负责人和公司管理层，让大家清楚当前服务器的整体运行状态。做完分级巡检的基础安排，我们还要进一步建立主动预防和应急处理的机制，毕竟巡检能发现大部分问题，但总有突发状况，只有把预防和应急都做足，才能真正稳住局面。2故障预防与应急处理机制我们运维常说“七分预防三分抢修”，把预防工作做到位，比出了问题再熬夜抢修强一百倍，真出了问题也要有成熟的流程，不能乱了阵脚。2.1主动预防措施首先是完善三级监控告警体系，我们把监控分成三个层级：第一层是基础资源监控，就是CPU、内存、磁盘这些基础指标；第二层是核心服务可用性监控，监控每个服务是不是能正常访问、进程是不是存活；第三层是业务链路监控，从用户访问到后端数据库返回，整条链路都监控，确保业务真的可用。告警也分等级，一般警告发工作群通知，严重告警直接给值班人员打手机加发短信，我们所有运维人员都是24小时不关机，要求严重告警10分钟内必须响应。其次是做好冗余架构，核心服务全部做了集群部署，数据库主备同步，单台服务器出问题自动切换，用户根本感知不到，网络也是双运营商线路，电源也是双冗余，之前一次运营商割接出问题，5秒就切到备用线路了，业务一点没受影响。最后是定期做压测，核心业务每季度都会做一次压力测试，提前找到性能瓶颈，解决在大流量到来之前。2.2分级故障应急响应我们按照故障影响范围把故障分成三个等级，不同等级对应不同的响应流程：一级故障是全业务宕机或者核心交易系统不可用，要求值班人员5分钟内到位启动应急预案，优先恢复业务，1小时内要恢复核心服务，同时第一时间通知相关负责人；二级故障是部分非核心业务异常，不影响整体运行，要求15分钟内响应，4小时内完成修复；三级故障是不影响使用的小异常，比如单台测试服务器指标异常，工作日工作时间处理完成就可以。这里我跟所有新来的同事都反复强调，故障处理第一原则是“先恢复，后排查”，不管什么原因，先把业务拉起来让用户能用，再慢慢找根因，不能光顾着查问题让用户一直等，那就是我们的失职。2.3故障复盘优化不管故障大小，处理完之后三个工作日内必须开复盘会，写复盘报告，要讲清楚故障发生的原因、我们处理过程中做的好的地方、做的不好的地方，最后要出具体的改进措施，避免下次再犯同样的错。之前我们出过一次日志自动切割没做，导致磁盘占满宕机的问题，复盘之后我们不仅加了定时自动清理日志的任务，还把磁盘告警阈值从原来的90%调到了80%，从那之后再也没出过同样的问题。把故障相关的机制理顺之后，我们还要持续做性能优化和容量规划，让服务器一直保持好的运行状态，不会越跑越慢，也不会临时手忙脚乱扩容。3性能优化与容量规划服务器不是搭好就不管了，随着业务增长，资源使用情况一直在变，只有持续优化、提前规划，才能一直稳定运行。3.1日常性能调优我们的性能调优分两个层面，系统层面和应用层面。系统层面我们会关掉所有不需要的系统服务，空出资源给业务用，再根据业务类型调整内核参数，比如我们核心业务并发量高，就调整了TCP连接复用参数，打开了快速回收，把并发能力提了一大块；应用层面重点优化数据库，每个季度我们都会把所有慢查询拉出来挨个过，该加索引加索引，该改SQL改SQL，该分库分表就提前做规划，之前有一个商品查询的SQL原来跑十几秒，优化之后不到一百毫秒，用户体验提升特别明显，我自己改完都觉得心里舒服。还有缓存，我们每个月都会整理一次缓存，清理掉没用的过期缓存，腾出内存空间，避免缓存膨胀拖慢整个服务。3.2容量评估与扩容规划容量规划最忌讳临时抱佛脚，我们每个月都会统计所有资源的使用增长趋势，比如磁盘每个月增长多少G，CPU和内存的峰值使用率每个季度涨多少，提前三个月预判什么时候需要扩容，提前做好采购或者开通的准备，不会等到资源不够用了才临时动手。比如每年的大促活动，我们都会提前两个月就把容量扩好，做完压测确认没问题才会放心，要是大促的时候资源爆了，那损失真的补不回来。所有的工作最终都是人来做的，所以我们还要做好人员管理和安全保障，这是整个方案能落地的根本。4人员管理与安全保障运维工作对责任心的要求远高于技术，只有把人安排好，把安全底线守住，整个保障体系才能正常运转。4.1人员排班与责任划分我们实行7*24小时轮班制，白天有两名运维人员在岗处理日常问题，晚上有一名人员待命，不管什么时候出问题都能找到人。我们把所有服务器和业务划分了责任到人，哪台核心服务器是谁负责，哪块业务是谁跟进，都写的清清楚楚，出了问题不会找不到负责人。新人来了之后，必须跟着老员工完整跑三个月的巡检、故障处理流程，熟悉所有规则之后才能独立上岗，我带新人的时候一直跟他们说，运维这个活，“稳”比“快”重要，多查一遍总没错，宁愿多花十分钟确认，也不要抱着“应该没问题”的心态放过一个小异常。4.2数据与网络安全保障安全是运维的底线，绝对不能出问题。首先是权限管理，我们严格遵循最小权限原则，每个员工只有自己工作需要的权限，核心服务器的最高权限只有两名运维负责人持有，所有操作都留审计日志，任何人操作都可追溯。然后是数据备份，我们严格遵循3-2-1备份原则：也就是保留3份完整数据，用2种不同的存储介质，1份存到异地机房，哪怕本地机房出了不可抗力的问题，核心数据也不会丢。最后是漏洞和攻击防护，每个月做一次全量漏洞扫描，高危漏洞72小时内必须修复，核心服务器都配置了Web应用防火墙，高频扫描、恶意攻击的IP直接拉黑，从入口就把风险挡住。整套方案不是一成不变的，随着业务发展和技术迭代，我们也要持续更新改进，才能一直贴合实际需求。5方案的持续改进我们这套方案不是写出来挂在墙上看的，是要每天用的，所以每季度我们都会组织全体运维人员对方案做一次复盘更新，把这段时间碰到的新问题、总结的新经验加进去，调整不合理的流程。比如今年我们上了一批云服务器，原来针对物理机的巡检规则不完全适用，我们就赶紧加了云服务器的专属巡检内容，调整了告警阈值，现在跑的就很顺。我们也会定期组织学习新的运维工具和技术，把原来重复的手动工作逐步自动化，腾出时间来做更深度的隐患排查和优化，慢慢提升我们的保障能力。方案总结做了这么多年运维，我最大的感受就是，运维的最好成绩就是“没动静”，用