运维工程师内功心法汇总
日常篇
1.当发现故障的时候,应该先恢复再排查,实在无计可施可以试试重启;
2.运维脚本要带上版本和备注,写清楚核心代码的作用;
3.脚本定义的变量名应该方便读取含义,以便后期需要对脚本进行修改时候降低读取代码的时长;
4.批量操作之前,应该先灰度再进行全量;
5.当你需要开放外网高危端口的时候,需要时刻铭记网络盘全规则,最后的红线前往不可触及;
6.对进程要时刻监控,避免出现僵尸进程消耗大量的进程号;
7.敏感或带有高风险的权限应该定期进行回收,人员离职或者转岗之前应该及时清理;
8.保持应用运行的独立性,防止交叉依赖的程序存在;不然挂一个可能死一片.然后赶紧买票吧!
9.每个出现的故障绝不是偶然,要相信"冰冻三尺绝非一日之寒",背后一定有必然的联系,找到问题的根源并优化掉;
10.时刻心中默念:责任心,沟通力,执行力;
11.运维工程师是每天必做的事情:打补丁,传文件,批处理,改配置,包管理,看监控;
12.对于运维对象,先量化管理再优化管理;
13.对可能产生不可逆后果的删除或修改操作,尽量延迟或者减速执行;
网络篇
1.生产网络的变更切记三思而后行,一个回车敲下去可能毁天灭地;
2.想要解放自己,要么学会coding,要么和程序员秃秃搞好关系;
3.网络监控不是监控网络,目的是对业务进行监控;
4.要分清楚链路的物理承载类型:裸纤直连,传输电路和二层专线;
5.当发现闪断问题的时候,要确定好抑制策略以及回切策略;
6.时刻握紧运维工程师的三把利剑:看告警,查光功率,环回测试;
7.要有提前预测问题的意识,提高对各种问题的重视程度;往往都是小变更出现故障,大变更因为关注度特别重视,所以往往反而不容易出现故障;
8.变更之前一定要进行环境检查,对于信息的收集必须要到位,变更后需要进行前后对比;
9.运维管理的核心价值在于建立完善的流程制度;
安全运维篇
1.尽可能的减少进程的启动权限,尽量不要使用root账号对进程进行启动;
2.系统的服务应该最小化,对无用的服务应该关闭或者停用;
3. 木马信息可以伪装和更改系统命令,系统内核调用也可能被替换;不能完全相信ps或者netstat所返回的信息;
4.被恶意攻击的时候,大量的会话状态跟踪表full日志会异常;
5.对抗CC攻击最简单有效的方法就是限制单IP的同时并发请求数;
6.对于syslog和authlog等日志需要进行定期的备份,便于安全事件的追朔和审计;
7.重要的密码一定不要全部设置成相同的,避免被撞库;
8.对于运行中的业务进程,切记不要将敏感信息输出到日志文件中,比如一些账号信息等,以免被抓包;
9.Shell或者Python代码的敏感逻辑一定要进行加密,输入账号密码的脚本中要对信息进行加密处理;
10.SSH远程登录一定要限制访问ip或者限制跳板机IP,系统与外界连接的渠道越少越好;
11.iptables的防火墙规则如果过多,将会大大的影响性能;
12.及时关闭PHP的相关危险函数和必须要的远程功能;
存储篇
1.数据的安全是底线,即使不服务也不能够造成数据的丢失;
2.在进行多份数据变更之前,先变更单份数据节点;
3.变更之前先准备回退方案,变更时先少量灰度;
4.带状态的模块一定要注意数据安全,因为索引数据非常重要,不要随意的迁移和删除;
5.更换磁盘之前必须多次检查SN号;
6.删除数据需再三确认,删除前对数据进行备份;避免删了库,只能跑路!
7.存储不能只关注容量,还需要关注inode的情况;
8.存储平台需要和计算机资源一起复用已达到设备的最大化利用;
9.不同年限的设备,存储速度和读写能力及性能肯定会存在差距,要区别对待不同年限的设备,老化的磁盘应该定期的进行检查病决定是否淘汰;
10.存储冷热数据要分离,业务一定要能识别冷数据;
数据库篇
1.没有规则的时候要学会制定规则,有规则的时候必须时刻遵守规则;
2.必须养成日常巡检核心监控属性的习惯;
3.数据库要具备;限流的能力;
4.遵循开发权限最小化原则,角色权限需划分清楚;
5.分库分表的规则需要在业务初期就规划好;
6.根据历史数据推算下一个容量高峰,提前做好容量度量;
7.根据访问类型规划好索引;
8.数据库应避免单点故障,指定高效的数据备份与恢复方案;
9.对业务要熟悉,对业务采用更适合的架构;
10.备份系统自动化,中心化调度,保证故障处理效率和可用性;
11.数据备份要做到百分百覆盖,百分百可恢复,定期进行恢复方案演练;
12.做到成本与效率的性价比最高;
MySQL运维篇
1.做好备份是基础，还需要经常性的做回复测试，检查数据的有效性；
2.管理用户和业务用户区分不同权限角色，不同级别的用户对应相符的权限，切记不能出现权限过高甚至是超越职权的情况出现；
3.做好数据库反入侵规划，不监听公网IP，用防火墙阻隔，降低被入侵的风险；
4.高innodb表性能，需要避免主从数据复制的延迟；
5.基数低的列建议放到联合索引中，并把基数高的放前面，基数低的放后面；
6.在进行性能测试和压力测试的时候，切记要把客户端和Server服务端分开；
7.当出现连接数爆满时，比起调高最大连接数，更加稳妥的做法是调低；
8.在进行环境初始化的时候，建议开启CPU最大性能模式；
9.造成MySQL进程占用CPU%user突然飙高，99.99%是因为索引不当导致；
10.对每个SQL条件建议加上引号，对用户输入的数据进行强制类型转换，可以避免SQL注入及类型隐式转换的风险；
11.不要直接删除数据表，而是在删除前应该先rename；删除大的表应该用硬链接的方式更加的高效；
自动化运维篇
1.自动化运维的终极目标是消灭SecureCRT和Putty等一切远程客户端，让平台成为唯一入口。
2.自动化运维的第一步是脚本化，通过脚本构建可重复的基础架构和环境。
3.优先考虑开源方案加二次开发满足运维要求。
4.高效是自动化运维的要求，使用多进程或者事件模型等可以提高并行处理效率。
5.安全必须是要内置在自动化运维中的，通过主动发现和深度防御机制保障安全。
6.集中控制节点和被控节点加密数据通信。
7.可以使用价值流程图分析当前的效率瓶颈和确认痛点。
8.自动化运维的底层数据必须保证完整性，技术手段与流程保障并行。
9.以自动探测和上报提高CMDB配置的效率和维护数据准确性。
10.监控体系的自动化是整个体系的纽带，它贯穿着事件和故障自愈。
11.在设计大规模监控体系的自动注册功能时，不以手动添加被监控指标。
12.坚持持续改进的监控目标，持续减少漏报和误报的比例。
CDN运营篇
1.SSL证书不能放在现网，必须独立管理。
2.要分平台域名，不能让DDos把整个平台打死。
3.必须关注回源率，回源率高的模型不适合CDN场景。
4.域名操作需谨慎，出了问题可能影响的整个服务。
5.HTTPS域名劫持最高优先级反馈至运营商。
6.内核是传输协议版本，传输协议是网络加速的利器，系统内核监控不能少。
7.Cache模型尽量使用分片淘汰模式，提升命中率。
8.核心业务调度要以本地覆盖调度模式优先，成本优先的业务以削峰填谷的调度模式优先。
9.用户层监控很重要，要有模拟或真实用户监控。
10.故障恢复时间能快则快，哪怕一分钟，TTL生效时间要针对业务适配。
11.调度系统和DNS 解析系统必须超过3地容灾部署，如果挂掉的话对全局的影响非常大。
12.CDN平台一定要有突发池，灵活调度才能保障整个系统的健康发展。
大数据运维篇
1.任何数据删除都要默认进入回收站，切记不要贪一时之快直接删除跳过回收站。
2.所有配置里的秘钥都需进行加密存储，时刻关注整个系统的安全。
3.轻量级非数据服务要有机房间切换的能力，加快恢复速度。
4.大规模和小规模场景不是量的变化，是质的差异。
5.实时计算链路长，延时敏感，要有各阶段的详细监控指标来反映问题，方便问题定位。
6.提供客户自助排查作业和重启等基础运维能力。
7.出问题的第一时间需要通知客户，否则客户的各种询问会让你痛不欲生！！！
8.存储瓶颈除了容量，文件数也是个大问题。
9.大规模计算平台至少要能容忍单机故障，存在单点故障的系统切记不能上线！！！
10.离在线混合部署是一个节约的好思路。
11.hdd&sdd混合存储提升shuffle性能。
12.规模大、压力大、要时刻关注硬件和网络发展，尽快拿到尽可能多的科技红利！
