您好，初次见面请多关照：）
本人陈东泉，08年1月参加工作，算起来马上就工作10年了，人生有多少个10年呢，套用歌手薛之嫌说的：“坚持也需要机遇”。
从机房的综合布线，做到目前出谋划策的IT顾问。运维的工作如此的繁琐繁重，想当年没人觉得你重要。一路走来，现在的运维，高格的运维是公司的核心，如何一路的走过来，是每位做从事计算机行业的一个过程，不管。是开发，测试，还是运维。
机缘巧合，参加了3月份深圳站的GOPS，参加完运维大会后对于拿到手的小宝典《运维三十六计》尤其是其中的《日常运维》部分颇有其中有些感慨。
当我逐条阅读时，脑海里，匆匆那年踩过的坑、犯过的错、一幕幕情景便记忆犹新，一一展现在了我的眼前：也是历史踩过的坑，无图无真相，只能通过文字描述分享给大家。
第十八记：敏感权限应定期回顾和检查，及时清理离职转岗的人员权限。
公司在发展，人员在变动，机器在增加，运维掌管的机器多不胜数，刚出来工作的时候需要管理批量UBUNTU桌面版。
事由：开发做ANDRIOD开发，如何统一用户账号密码做好管理呢？
当时采用NIS服务，集中管理用户信息。踩了什么坑呢？它每加一个用户都需要更新一下服务数据库，但是搞ANDRIOD开发人员多，经常每周都有入职离职转岗。
一天一个甲开发人员，登录操作系统后无权限访问自己的文件夹，经过排查，只是刚离职人员与新来的同事同名，更新数据时没有设置好权限。
又一天，B开发说为什么我可以看到对方文件夹，我要有权限访问这个目录，这是需要走流程申请才可以给予，当时没想太多直接开放权限，结果当然是被发现了，工作要细心。
所以大家一定要有一个规划规范流程。
后续采用WINDOWS的AD方式管理用户，PAM模块。在有规划下规范下管理工作才是治标治本，一切为了日后工作的便利。
第二十五记：运维工作互备，工作交接要留文档。
这坑，每个人都应该踩一下，记得当时一家公司大了人员多了，同事也多。
事由：记得一次上线，反代NGINX配置多样性，你想实现的花点时间总成功我们公司分工，运维分了外网运维，内网运维各自维护公司在内服务器，及在外服务器。
当初一个需求，外网需求301跳转，要从500条记录中，找出有价值的URL地址，做统一跳转，花了好多时间去实现后，沾沾自喜。
隔天请假，同事帮忙操作，需求变更，说跳转有错误，需要修改，内网运维同事，直接先把原来的备份还原，再重复我做的工作，这时事情发生了。
市场已经投了广告，他重新为了一些修改再花了更多时间去实现需求，导致业务人员投诉，不该出现的URL地址为什么出现，最后收入少了还不是问题，直接那个季度评级C。
自从那次后，处理手段是WIKI的建立，每周工作日五天，其中两天都在写文档，为的不是自己做了有多少东西，为的是减少工作上的摩擦，记得口说无凭，必须记录。
第二十九记：运维规范变现步骤：文档化，工具化，系统化，自动化。
这类坑，可以理解为踩多了需要总结，曾经做的工作没有记录，别人怎么接手？
工作繁琐，不用工具怎么减少时间，做更有用的事情？
不做规划，怎么系统的去管理服务？
说到自动，真的是个高大上的活，这是一个团体才可以产出的结果，同理没有一系列的铺垫，没有精力如何做出满意的工作？
工作上，只能说尽量想多点，不要为了做而做，做完了要回想回顾我应该下一次如何做更好，然后记录，使用便捷工具如ANSBILE，量多了考虑JENKINS管理包，配合脚本实现简单发布。
当年一家公司，刚去到几台WINDOWS服务器，还好都是JAVA代码，就帮助开发们全部迁移至LINUX环境，没有文档咋办，尝试操作，把每一步做的过程记录下来就有文档了。
同时也有新的业务开发，那就搞个FTP，代码统一上传，后台调用RSYNC，封装个页面给测试人员更新，这样简单的拼凑工具就出现了。后来量大了，批量服务器到位，当时就全盘规划，把物理机全部换成VM，把部署应用环境打包好，代码按照制定的格式目录打包好。
来一台分发一台，当然也是一些开源工具的组合，但是必须有高度去看，我要做什么，要做出什么样子。系统的考虑实现方式。后来离职了，给予公司的建议，就是如何产品化把平台搭建起来，把开发，测试，运维做的事情打通，知己知彼。
以上三记，自我感觉是范范要做好，规范少不了。
还有其他计谋也挺在意的，比如以下三记：
第三十一记：容量管理要做好，每日管制高低负载。
这事没做好真的不是个称职的运维，记得当时在一家公司，还没上监控前，出现一次问题，APACHE提供OA服务，突然无法访问，检查服务端口正常，查看程序正常，通过访问日志没有访问记录，查看系统的/ var /日志/消息，提示磁盘满了。
说到这里，在/ var /日志/消息这个文件真的是运维必备查阅地方，基本百试百灵。
满了咋办，找问题，原来是共享磁盘NFS的分区满了，简单做法，删除即可。
后续归纳为需要写个脚本定期检查所有机器的CPU，内存，容量，通过NAGIOS每天发邮件的检查内容。你说监控管理多么的重要。
第三十三记：日志管理使用轮换机制，防止硬盘空间使用率无限增大。
这问题跟没有做好容量管理差不多，记得一次也是容量满了，查询发现是NGINX写的文件10G，10G多个，就几百个G了，当年一台机器有上百个域名，可想而知，日志切割的必要性。同时也是监控点，要把重要的路径做出监控列表，监控上，才对得起自己。
后来通过仙人掌画图，每周做评估。
第三十五记：容量规划牢记从3个角度评估：主机负载，应用性能，业务请求量。
这完全就是需要一个监控平台来管理，曾经在公司出现以下多个问题：
网站慢呀，翻查一看核心网络出问题，出现断断续续，询问机房被攻击，只能更换IP地址，后续加多个外围反代。
又出现，网站慢呀，翻查一看，一些反代到核心机房网络异常，断断续续。怎么办？更换反代节点。
又来了，网站慢呀，翻查一看，CDN到某些反代网络异常，也是断断续续，这找CDN，他们的出口网络不稳定。
网站卡了，这次从CDN，反代，核心机房都找完了，发现代码计算出现问题，告诉开发改良。
又有一次这功能有问题，为什么这请求这么高，导致核心应用无响应？加多个NGINX分流来才能解决问题，才用HA提高可用性。当然最后通过访问日志分析，就是开发自己死命的访问自己写个数据，数据本身有问题，导致重复。
总得来说因为监控不到位，反思如何工作，才能减少问题的出现，当时就归类监控内容：操作系统【CPU，内存，磁盘，IO】，网络【PING，流量】，应用【NGINX，Redis的， TOMCAT等】，业务【叫开发写个JASON接口获取数据】。只有这样才可以预先知道问题，定位问题。
调研后使用主流的ZABBIX软件，整合数据基本达到目的。
最后，第三十六记：保持运维对象的标准化与一致性，处女座版梳理整洁生产环境。
这记要是做不到，很难释放生产力，说白了就是喝口水也没有时间。
比如：今天一个发布公司内网OA系统，同时有同事叫你查阅外网CRM日志，又同时有同事叫你去开会，怎么办这是大家都可能遇到的事件，所以把要把事情做好。
如DEVOPS文化一样，先按部就班，做好“标准化”，为什么带引号，各家公司业务都不一样，没有统一，只有实践出真理，先满足工作，再是如何做好，然后如何更好的展示工作。
写了这么多，也是很感谢大家看完，再次感谢高效运维社区，和业内前辈总结出这本宝典，浓缩的都是精华，相信这本小册子和高效运维社区会一样，会一直陪伴着我的职业生涯。
征稿大事件
首先灰常感谢陈东泉同学用心码了这么多字。我想很多读过这本《运维三十六计》的朋友也顿时才思泉涌想抒发下自己的真情实感！
重磅消息！
先开启征稿阶段 ~~
没有小册子的可以长按以下二维码，阅读电子版
如果这本《运维三十六计》也让您产生了共鸣，让您想起了过去的辛酸血泪史，甚至成为了您工作的小助手，欢迎您写下您的想法和感悟，给我们投稿，邮箱：[email protected]
一旦稿件被采用，您将有机会获得 7月28日GOPS北京站门票 或者 8月18日DevOpsDays 上海站门票一张，waiting for you ：）
《运维三十六计》将增加持续交付、持续部署等更多计策内容升级为豪华版《DevOps 三十六计》，主编梁定安（腾讯 织云负责人）
想得到？728 · GOPS全球运维大会 · 北京站等你来拿。
点击原文链接，报名参会！
