运维
运维平台信用分——滴滴内部的数据驱动实践
老马 发表了文章 • 0 个评论 • 164 次浏览 • 2019-05-25 21:03
【编者的话】在大家的印象中，运维人员更多的是从属业务的角色。在传统的企业IT中，没有快速的产品迭代，没有每天成百上千次的服务发布和伸缩容，这样的角色看似没有问题。但在如今的 DevOps 时代，日常的运维工作中每天要应对成百上千次的服务发布与线上操作。如果运维 ...查看全部
【编者的话】在大家的印象中，运维人员更多的是从属业务的角色。在传统的企业IT中，没有快速的产品迭代，没有每天成百上千次的服务发布和伸缩容，这样的角色看似没有问题。但在如今的 DevOps 时代，日常的运维工作中每天要应对成百上千次的服务发布与线上操作。如果运维人员（即SRE）仍然只是被动的去应对这种变化，所造成的结果，必然是疲于应付，最终会对全平台的业务稳定性造成很大隐患。
那么，在这种量变引起质变的挑战中，运维人员应该发挥怎样的作用，才能适应新业务的挑战呢？笔者之前曾就职于IBM Cloud部门，现在就职于滴滴运维部，长期从事自动化运维方面的工作，下面就结合自己之前的经验和目前的工作，谈谈自己的一些见解。如果你想和更多运维技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
#来自业务的挑战
无论是在滴滴还是在之前的部门，在业务发展的初期阶段，都不可避免的经历了粗犷型的扩张阶段，比如业务量指数级上升，用户量急剧增加，每时每刻都有服务模块的迭代。
在业务优先的前提下，运维人员承担着巨大的运维压力。以监控为例，用户添加监控不规范，会造成报警频发，报警有效性不足，导致的后果就是容易让真正有价值的报警湮没在海量数据中，同时，也会造成对报警资源的浪费，比如，研发同学不区分测试、线上环境，随意的添加报警采集指标，会对监控系统的存储，查询带来极大的挑战。再比如部署系统，不按照规范，在高峰期更新服务，一旦出问题，会造成整个应用的服务不可用。这样的例子有很多。
#如何应对
如果上述的问题一直延续下去，运维工作必然带来巨大的挑战，并且会严重影响线上服务的稳定性。面对这些问题，滴滴运维团队的同学也在一起思考，运维应该不仅仅去被动的适应业务，而是要从平台稳定性出发，去指导研发同学，如何规范的执行变更，如何合理的使用监控资源以及其它公司IT基础设施。
我们想到的解决方法就是“数据说话”，尽可能的去量化监控、部署及基础组件（MySQL、Codis、ZooKeeper）的使用。然后用数字去指导研发的同学，尽可能的去匹配我们给出的“最佳实践”，从而减少造成线上业务不稳定的隐患。
所以，滴滴运维部推出了“风险量化平台”，包含“变更信用分”（用来度量服务的变更操作，比如服务部署上线，配置变更等）、“监控健康分”（用来度量用户对报警监控的使用），从而打造一个“看得见的手”，驱动业务同学来一起提高线上稳定性。
##数据驱动的难点有三个方面
首先是如何获取数据？这是“风险量化平台”的基础。使用监控系统，部署一个服务，执行一次配置变更，都是一个个用户操作，很难用数字去表达。为此我们结合运维经验，基于对操作每个步骤的详尽输出，近可能的去用数字维度来衡量用户操作。比如以部署为例，会以灰度发布中间的暂停时间是否满足一定时长，是否有在上线高峰期操作记录，部署过程中是否执行了double-check，在哪个阶段执行了回滚等等，来形成一个个的打分项。
其次是如何去制定风险量化的标准，也就是如何用各个指标去构造一个最佳实践。这更像是一个数学建模，里面涉及到大量的运维经验积累，以我们新推出的监控健康分为例，我们遵循着“有服务必有监控，有报警必须处理”的原则，对于每个服务，要求衡量的标准包括，是否有存活指标监控（进程、端口等）；是否有基础指标监控（如cpu.idle，mem.used，disk.used）；是否添加了上下游监控，报警是否有效，即报警接收人是否过多（因为大家都收到报警，最终的结果，往往意味着大家都不会处理报警），报警是否被及时处理（运维领域也有MTTA， MTTR，即报警平均响应时间，和报警及时处理时间这样的概念）；是否配置了监控大盘，方便我们日常巡检。
各个量化项目占据不同的权重（如下方的监控健康分剖析图）， 比如我们根据滴滴目前的服务特点，存活指标占比40%， 报警有效性占比30%，推动业务去收敛报警，和完善监控。监控健康分以80分为及格线，寻找出监控漏洞，并指导用户加以改进。 用这样的方法，可以让研发同学尽可能的减少漏配监控的事情发生，提高线上服务的稳定性。
最后的难点是如何驱动？这是我们现在着力想的一个点。风险量化实际上就是总结前人踩过的坑，趟过的雷，去告诉后面的同学，提前来规避风险，这是运维部门对公司业务稳定性的一大贡献。
现在已有的做法是如下图（各部门变更信用分排名图）所示，通过计算、打分、全公司各个业务线排名，将风险量化数据和反应出的问题推送给各个业务线的leader。以竞赛方式去推动各个业务线重视风险量化。我们还计划以监控健康分去驱动报警有效性的建设，完善报警值班制度，避免群发报警又无人处理，报警配置不合理这种现象的发生。
#效果如何
目前的风险量化体系包含“变更信用分”，“监控健康分”，其中变更信用分已经上线一年多了，在2018年，从下图能明显看到信用分在稳步上升。
带来结果是什么呢？ 下面是本年度故障case统计图，能明显的看到这种趋势，故障case数量随着变更信用分的提高在稳步下降。考虑到同时期的变更数量也在一直增加，这种下降趋势就更加明显了。
我们期望其它的信用分机制，也能给业务稳定性带来这样积极的结果。
#未来展望
对于未来的展望，首先希望能对尽可能多的涉及线上操作的内容进行风险量化，比如业务使用的中间件／基础组件，业务中涉及安全的服务是否遵循了相应的规范，是否有密码／数据泄漏风险。
其次，我们仍然需要对已有的运维经验进行总结，结合经验，利用量化分数去构建“最佳实践”，指导大家去遵守。
最后是如何去驱动，将总结的数据价值，最大化的发挥出来。
原文链接：https://mp.weixin.qq.com/s/AYjpv2GSYDLl0pB9tHqkrg
那么，在这种量变引起质变的挑战中，运维人员应该发挥怎样的作用，才能适应新业务的挑战呢？笔者之前曾就职于IBM Cloud部门，现在就职于滴滴运维部，长期从事自动化运维方面的工作，下面就结合自己之前的经验和目前的工作，谈谈自己的一些见解。如果你想和更多运维技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
#来自业务的挑战
无论是在滴滴还是在之前的部门，在业务发展的初期阶段，都不可避免的经历了粗犷型的扩张阶段，比如业务量指数级上升，用户量急剧增加，每时每刻都有服务模块的迭代。
在业务优先的前提下，运维人员承担着巨大的运维压力。以监控为例，用户添加监控不规范，会造成报警频发，报警有效性不足，导致的后果就是容易让真正有价值的报警湮没在海量数据中，同时，也会造成对报警资源的浪费，比如，研发同学不区分测试、线上环境，随意的添加报警采集指标，会对监控系统的存储，查询带来极大的挑战。再比如部署系统，不按照规范，在高峰期更新服务，一旦出问题，会造成整个应用的服务不可用。这样的例子有很多。
#如何应对
如果上述的问题一直延续下去，运维工作必然带来巨大的挑战，并且会严重影响线上服务的稳定性。面对这些问题，滴滴运维团队的同学也在一起思考，运维应该不仅仅去被动的适应业务，而是要从平台稳定性出发，去指导研发同学，如何规范的执行变更，如何合理的使用监控资源以及其它公司IT基础设施。
我们想到的解决方法就是“数据说话”，尽可能的去量化监控、部署及基础组件（MySQL、Codis、ZooKeeper）的使用。然后用数字去指导研发的同学，尽可能的去匹配我们给出的“最佳实践”，从而减少造成线上业务不稳定的隐患。
所以，滴滴运维部推出了“风险量化平台”，包含“变更信用分”（用来度量服务的变更操作，比如服务部署上线，配置变更等）、“监控健康分”（用来度量用户对报警监控的使用），从而打造一个“看得见的手”，驱动业务同学来一起提高线上稳定性。
##数据驱动的难点有三个方面
首先是如何获取数据？这是“风险量化平台”的基础。使用监控系统，部署一个服务，执行一次配置变更，都是一个个用户操作，很难用数字去表达。为此我们结合运维经验，基于对操作每个步骤的详尽输出，近可能的去用数字维度来衡量用户操作。比如以部署为例，会以灰度发布中间的暂停时间是否满足一定时长，是否有在上线高峰期操作记录，部署过程中是否执行了double-check，在哪个阶段执行了回滚等等，来形成一个个的打分项。
其次是如何去制定风险量化的标准，也就是如何用各个指标去构造一个最佳实践。这更像是一个数学建模，里面涉及到大量的运维经验积累，以我们新推出的监控健康分为例，我们遵循着“有服务必有监控，有报警必须处理”的原则，对于每个服务，要求衡量的标准包括，是否有存活指标监控（进程、端口等）；是否有基础指标监控（如cpu.idle，mem.used，disk.used）；是否添加了上下游监控，报警是否有效，即报警接收人是否过多（因为大家都收到报警，最终的结果，往往意味着大家都不会处理报警），报警是否被及时处理（运维领域也有MTTA， MTTR，即报警平均响应时间，和报警及时处理时间这样的概念）；是否配置了监控大盘，方便我们日常巡检。
各个量化项目占据不同的权重（如下方的监控健康分剖析图）， 比如我们根据滴滴目前的服务特点，存活指标占比40%， 报警有效性占比30%，推动业务去收敛报警，和完善监控。监控健康分以80分为及格线，寻找出监控漏洞，并指导用户加以改进。 用这样的方法，可以让研发同学尽可能的减少漏配监控的事情发生，提高线上服务的稳定性。
最后的难点是如何驱动？这是我们现在着力想的一个点。风险量化实际上就是总结前人踩过的坑，趟过的雷，去告诉后面的同学，提前来规避风险，这是运维部门对公司业务稳定性的一大贡献。
现在已有的做法是如下图（各部门变更信用分排名图）所示，通过计算、打分、全公司各个业务线排名，将风险量化数据和反应出的问题推送给各个业务线的leader。以竞赛方式去推动各个业务线重视风险量化。我们还计划以监控健康分去驱动报警有效性的建设，完善报警值班制度，避免群发报警又无人处理，报警配置不合理这种现象的发生。
#效果如何
目前的风险量化体系包含“变更信用分”，“监控健康分”，其中变更信用分已经上线一年多了，在2018年，从下图能明显看到信用分在稳步上升。
带来结果是什么呢？ 下面是本年度故障case统计图，能明显的看到这种趋势，故障case数量随着变更信用分的提高在稳步下降。考虑到同时期的变更数量也在一直增加，这种下降趋势就更加明显了。
我们期望其它的信用分机制，也能给业务稳定性带来这样积极的结果。
#未来展望
对于未来的展望，首先希望能对尽可能多的涉及线上操作的内容进行风险量化，比如业务使用的中间件／基础组件，业务中涉及安全的服务是否遵循了相应的规范，是否有密码／数据泄漏风险。
其次，我们仍然需要对已有的运维经验进行总结，结合经验，利用量化分数去构建“最佳实践”，指导大家去遵守。
最后是如何去驱动，将总结的数据价值，最大化的发挥出来。
原文链接：https://mp.weixin.qq.com/s/AYjpv2GSYDLl0pB9tHqkrg
运维工程师不得不看的经验教训和注意事项
大卫 发表了文章 • 0 个评论 • 222 次浏览 • 2019-05-22 19:48
#一、线上操作规范
##测试使用
当初学习Linux的使用，从基础到服务到集群，都是在虚拟机做的，虽然老师告诉我们跟真机没有什么差别，可是对真实环境的渴望日渐上升，不过虚拟机的各种快照却让我们养成了各种手贱的习惯，以致于拿到服务器操作权 ...查看全部
#一、线上操作规范
##测试使用
当初学习Linux的使用，从基础到服务到集群，都是在虚拟机做的，虽然老师告诉我们跟真机没有什么差别，可是对真实环境的渴望日渐上升，不过虚拟机的各种快照却让我们养成了各种手贱的习惯，以致于拿到服务器操作权限时候，就迫不及待的想去试试，记得上班第一天，老大把root密码交给我，由于只能使用putty，我就想使用xshell，于是悄悄登录服务器尝试改为xshell+密钥登录，因为没有测试，也没有留一个ssh连接，所有重启sshd服务器之后，自己就被挡在服务器之外了，幸好当时我备份了sshd_config文件，后来让机房人员cp过去就可以了，幸亏这是一家小公司，不然直接就被干了……庆幸当年运气比较好。如果你想和更多运维技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
第二个例子是关于文件同步的，大家都知道rsync同步很快，可是他删除文件的速度大大超过了rm -rf，在rsync中有一个命令是，以某目录为准同步某文件（如果第一个目录是空的，那么结果可想而知），源目录（有数据的）就会被删除，当初我就是因为误操作，以及缺乏测试，就目录写反了，关键是没有备份……生产环境数据被删了
没备份，大家自己想后果吧，其重要性不言而喻。
##Enter前再三确认
关于rm -rf / var这种错误，我相信手快的人，或者网速比较慢的时候，出现的几率相当大
当你发现执行完之后，你的心至少是凉了半截。
大家可能会说，我按了这么多次都没出过错，不用怕，我只想说当出现一次你就明白了，不要以为那些运维事故都是在别人身上，如果你不注意，下一个就是你。
##切忌多人操作
我在的上一家公司，运维管理相当混乱，举一个最典型的例子吧，离职好几任的运维都有服务器root密码。
通常我们运维接到任务，都会进行简单查看如果无法解决，就请求他人帮忙，可是当问题焦头烂额的时候，客服主管（懂点Linux），网管，你上司一起调试一个服务器，当你各种百度,各种对照，完了发现，你的服务器配置文件，跟上次你修改不一样了，然后再改回来，然后再谷歌，兴冲冲发现问题，解决了，别人却告诉你，他也解决了，修改的是不同的参数……这个，我就真不知道哪个是问题真正的原因了，当然这还是好的，问题解决了，皆大欢喜，可是你遇到过你刚修改的文件，测试无效，再去修改发现文件又被修改的时候呢？真的很恼火，切忌多人操作。
##先备份后操作
养成一个习惯，要修改数据时，先备份，比如.conf的配置文件。另外，修改配置文件时，建议注释原选项，然后再复制，修改，再者说，如果第一个例子中，有数据库备份，那rsync的误操作不久没事了吧。所以说丢数据库非一朝一夕，随便备份一个就不用那么惨。
#二、涉及数据
##慎用rm -rf
网上的例子很多，各种rm -rf /，各种删除主数据库，各种运维事故……
一点小失误就会造成很大的损失。如果真需要删除，一定要谨慎。
##备份大于一切
本来上面都有各种关于备份，但是我想把它划分在数据类再次强调，备份非常之重要哇。我记得我的老师说过一句话，涉及到数据何种的谨慎都不为过。我就职的公司有做第三方支付网站和网贷平台的，第三方支付是每两个小时完全备份一次，网贷平台是每20分钟备份一次，我不多说了，大家自己斟酌吧。
##稳定大于一切
其实不止是数据，在整个服务器环境，都是稳定大于一切，不求最快，但求最稳定，求可用性。所以未经测试，不要再服务器使用新的软件，比如Nginx+php-fpm，生产环境中PHP各种挂啊。重启下就好了，或者换apache就好了。
##保密大于一切
现在各种艳照门漫天飞，各种路由器后门，所以说，涉及到数据，不保密是不行的。
##三、涉及安全
##SSH
* 更改默认端口（当然如果专业要黑你，扫描下就出来了）
* 禁止root登录
* 使用普通用户+key认证+sudo规则+IP地址+用户限制
* 使用hostdeny类似的防爆里破解软件（超过几次尝试直接拉黑）
* 筛选/etc/passwd中login的用户
##防火墙
防火墙生产环境一定要开，并且要遵循最小原则，drop所有，然后放行需要的服务端口。
##精细权限和控制粒度
能使用普通用户启动的服务坚决不使用root，把各种服务权限控制到最低，控制粒度要精细。
##入侵检测和日志监控
* 使用第三方软件，时刻检测系统关键文件以及各种服务配置文件的改动，比如：/etc/passwd，/etc/my.cnf，/etc/httpd/con/httpd.con等；
* 使用集中化的日志监控体系，监控/var/log/secure，/etc/log/message，ftp上传下载文件等报警错误日志；
* 另外针对端口扫描，也可以使用一些第三方软件，发现被扫描就直接拉入host.deny。这些信息对于系统被入侵后排错很有帮助。有人说过，一个公司在安全投入的成本跟他被安全攻击损失的成本成正比，安全是一个很大的话题。
也是一个很基础的工作，把基础做好了，就能相当的提高系统安全性，其他的就是安全高手做的了
#四、日常监控
##系统运行监控
好多人踏入运维都是从监控做起，大的公司一般都有专业24小时监控运维。系统运行监控一般包括硬件占用率，常见的有：内存，硬盘，CPU，网卡，os包括登录监控，系统关键文件监控。
定期的监控可以预测出硬件损坏的概率，并且给调优带来很实用的功能
##服务运行监控
服务监控一般就是各种应用，Web，DB，LVS等，这一般都是监控一些指标。
在系统出现性能瓶颈的时候就能很快发现并解决。
##日志监控
这里的日志监控跟安全的日志监控类似，但这里一般都是硬件，os，应用程序的报错和警报信息。
监控在系统稳定运行的时候确实没啥用，但是一旦出现问题，你又没做监控，就会很被动了。
#五、性能调优
##深入了解运行机制
其实按一年多的运维经验来说，谈调优根本就是纸上谈兵，但是我只是想简单总结下，如果有更深入的了解，我会更新。在对软件进行优化之前，比如要深入了解一个软件的运行机制，比如Nginx和Apache，大家都说Nginx快，那就必须知道Nginx为什么快，利用什么原理，处理请求比Apache，并且要能跟别人用浅显易懂的话说出来，必要的时候还要能看懂源代码，否则一切以参数为调优对象的文档都是瞎谈。
##调优框架以及先后
熟悉了底层运行机制，就要有调优的框架和先后顺序，比如数据库出现瓶颈，好多人直接就去更改数据库的配置文件，我的建议是，先根据瓶颈去分析，查看日志，写出来调优方向，然后再入手，并且数据库服务器调优应该是最后一步，最先的应该是硬件和操作系统，现在的数据库服务器都是在各种测试之后才会发布的。
适用于所有操作系统，不应该先从他入手。
##每次只调一个参数
每次只调一个参数，这个相比大家都了解，调的多了，你就自己就迷糊了。
##基准测试
判断调优是否有用，和测试一个新版本软件的稳定性和性能等方面，就必须要基准测试了，测试要涉及很多因素。
测试是否接近业务真实需求这要看测试人的经验了，相关资料大家可以参考《高性能MySQL》第三版相当的好。
我的老师曾说过，没有放之四海皆准的参数，任何参数更改任何调优都必须符合业务场景，所以不要再谷歌什么什么调优了，对你的提升和业务环境的改善没有长久作用
#六、运维心态
##控制心态
很多rm -rf /data都在下班的前几分钟，都在烦躁的高峰，那么你还不打算控制下你的心态么？
有人说了，烦躁也要上班，可是你可以在烦躁的时候尽量避免处理关键数据环境。
越是有压力，越要冷静，不然会损失更多。
大多人都有rm -rf /data/mysql的经历，发现删除之后，那种心情你可以想象一下，可是如果没有备份，你急又有什么用，一般这种情况下，你就要冷静想下最坏打算了，对于MySQL来说，删除了物理文件，一部分表还会存在内存中，所以断开业务，但是不要关闭mysql数据库，这对恢复很有帮助，并使用dd复制硬盘，然后你再进行恢复。
当然了大多时候你就只能找数据恢复公司了。
试想一下，数据被删了，你各种操作，关闭数据库，然后修复，不但有可能覆盖文件，还找不到内存中的表了。
##对数据负责
生产环境不是儿戏，数据库也不是儿戏，一定要对数据负责。不备份的后果是非常严重的。
##追根究底
很多运维人员比较忙，遇到问题解决就不会再管了，记得去年一个客户的网站老是打不开，经过PHP代码报错。
发现是session和whos_online损坏，前任运维是通过repair修复的，我就也这样修复了，但是过了几个小时，又出现了。
反复三四次之后，我就去谷歌数据库表莫名损坏原因：一是MyISAM的bug，二是mysqlbug，三是MySQL在写入过程中
被kill，最后发现是内存不够用，导致OOM kill了mysqld进程。
并且没有swap分区，后台监控内存是够用的，最后升级物理内存解决。
##测试和生产环境
在重要操作之前一定要看自己所在的机器，尽量避免多开窗口。
原文链接：http://www.cnblogs.com/yihr/p/9593795.html
##测试使用
当初学习Linux的使用，从基础到服务到集群，都是在虚拟机做的，虽然老师告诉我们跟真机没有什么差别，可是对真实环境的渴望日渐上升，不过虚拟机的各种快照却让我们养成了各种手贱的习惯，以致于拿到服务器操作权限时候，就迫不及待的想去试试，记得上班第一天，老大把root密码交给我，由于只能使用putty，我就想使用xshell，于是悄悄登录服务器尝试改为xshell+密钥登录，因为没有测试，也没有留一个ssh连接，所有重启sshd服务器之后，自己就被挡在服务器之外了，幸好当时我备份了sshd_config文件，后来让机房人员cp过去就可以了，幸亏这是一家小公司，不然直接就被干了……庆幸当年运气比较好。如果你想和更多运维技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
第二个例子是关于文件同步的，大家都知道rsync同步很快，可是他删除文件的速度大大超过了rm -rf，在rsync中有一个命令是，以某目录为准同步某文件（如果第一个目录是空的，那么结果可想而知），源目录（有数据的）就会被删除，当初我就是因为误操作，以及缺乏测试，就目录写反了，关键是没有备份……生产环境数据被删了
没备份，大家自己想后果吧，其重要性不言而喻。
##Enter前再三确认
关于rm -rf / var这种错误，我相信手快的人，或者网速比较慢的时候，出现的几率相当大
当你发现执行完之后，你的心至少是凉了半截。
大家可能会说，我按了这么多次都没出过错，不用怕，我只想说当出现一次你就明白了，不要以为那些运维事故都是在别人身上，如果你不注意，下一个就是你。
##切忌多人操作
我在的上一家公司，运维管理相当混乱，举一个最典型的例子吧，离职好几任的运维都有服务器root密码。
通常我们运维接到任务，都会进行简单查看如果无法解决，就请求他人帮忙，可是当问题焦头烂额的时候，客服主管（懂点Linux），网管，你上司一起调试一个服务器，当你各种百度,各种对照，完了发现，你的服务器配置文件，跟上次你修改不一样了，然后再改回来，然后再谷歌，兴冲冲发现问题，解决了，别人却告诉你，他也解决了，修改的是不同的参数……这个，我就真不知道哪个是问题真正的原因了，当然这还是好的，问题解决了，皆大欢喜，可是你遇到过你刚修改的文件，测试无效，再去修改发现文件又被修改的时候呢？真的很恼火，切忌多人操作。
##先备份后操作
养成一个习惯，要修改数据时，先备份，比如.conf的配置文件。另外，修改配置文件时，建议注释原选项，然后再复制，修改，再者说，如果第一个例子中，有数据库备份，那rsync的误操作不久没事了吧。所以说丢数据库非一朝一夕，随便备份一个就不用那么惨。
#二、涉及数据
##慎用rm -rf
网上的例子很多，各种rm -rf /，各种删除主数据库，各种运维事故……
一点小失误就会造成很大的损失。如果真需要删除，一定要谨慎。
##备份大于一切
本来上面都有各种关于备份，但是我想把它划分在数据类再次强调，备份非常之重要哇。我记得我的老师说过一句话，涉及到数据何种的谨慎都不为过。我就职的公司有做第三方支付网站和网贷平台的，第三方支付是每两个小时完全备份一次，网贷平台是每20分钟备份一次，我不多说了，大家自己斟酌吧。
##稳定大于一切
其实不止是数据，在整个服务器环境，都是稳定大于一切，不求最快，但求最稳定，求可用性。所以未经测试，不要再服务器使用新的软件，比如Nginx+php-fpm，生产环境中PHP各种挂啊。重启下就好了，或者换apache就好了。
##保密大于一切
现在各种艳照门漫天飞，各种路由器后门，所以说，涉及到数据，不保密是不行的。
##三、涉及安全
##SSH
* 更改默认端口（当然如果专业要黑你，扫描下就出来了）
* 禁止root登录
* 使用普通用户+key认证+sudo规则+IP地址+用户限制
* 使用hostdeny类似的防爆里破解软件（超过几次尝试直接拉黑）
* 筛选/etc/passwd中login的用户
##防火墙
防火墙生产环境一定要开，并且要遵循最小原则，drop所有，然后放行需要的服务端口。
##精细权限和控制粒度
能使用普通用户启动的服务坚决不使用root，把各种服务权限控制到最低，控制粒度要精细。
##入侵检测和日志监控
* 使用第三方软件，时刻检测系统关键文件以及各种服务配置文件的改动，比如：/etc/passwd，/etc/my.cnf，/etc/httpd/con/httpd.con等；
* 使用集中化的日志监控体系，监控/var/log/secure，/etc/log/message，ftp上传下载文件等报警错误日志；
* 另外针对端口扫描，也可以使用一些第三方软件，发现被扫描就直接拉入host.deny。这些信息对于系统被入侵后排错很有帮助。有人说过，一个公司在安全投入的成本跟他被安全攻击损失的成本成正比，安全是一个很大的话题。
也是一个很基础的工作，把基础做好了，就能相当的提高系统安全性，其他的就是安全高手做的了
#四、日常监控
##系统运行监控
好多人踏入运维都是从监控做起，大的公司一般都有专业24小时监控运维。系统运行监控一般包括硬件占用率，常见的有：内存，硬盘，CPU，网卡，os包括登录监控，系统关键文件监控。
定期的监控可以预测出硬件损坏的概率，并且给调优带来很实用的功能
##服务运行监控
服务监控一般就是各种应用，Web，DB，LVS等，这一般都是监控一些指标。
在系统出现性能瓶颈的时候就能很快发现并解决。
##日志监控
这里的日志监控跟安全的日志监控类似，但这里一般都是硬件，os，应用程序的报错和警报信息。
监控在系统稳定运行的时候确实没啥用，但是一旦出现问题，你又没做监控，就会很被动了。
#五、性能调优
##深入了解运行机制
其实按一年多的运维经验来说，谈调优根本就是纸上谈兵，但是我只是想简单总结下，如果有更深入的了解，我会更新。在对软件进行优化之前，比如要深入了解一个软件的运行机制，比如Nginx和Apache，大家都说Nginx快，那就必须知道Nginx为什么快，利用什么原理，处理请求比Apache，并且要能跟别人用浅显易懂的话说出来，必要的时候还要能看懂源代码，否则一切以参数为调优对象的文档都是瞎谈。
##调优框架以及先后
熟悉了底层运行机制，就要有调优的框架和先后顺序，比如数据库出现瓶颈，好多人直接就去更改数据库的配置文件，我的建议是，先根据瓶颈去分析，查看日志，写出来调优方向，然后再入手，并且数据库服务器调优应该是最后一步，最先的应该是硬件和操作系统，现在的数据库服务器都是在各种测试之后才会发布的。
适用于所有操作系统，不应该先从他入手。
##每次只调一个参数
每次只调一个参数，这个相比大家都了解，调的多了，你就自己就迷糊了。
##基准测试
判断调优是否有用，和测试一个新版本软件的稳定性和性能等方面，就必须要基准测试了，测试要涉及很多因素。
测试是否接近业务真实需求这要看测试人的经验了，相关资料大家可以参考《高性能MySQL》第三版相当的好。
我的老师曾说过，没有放之四海皆准的参数，任何参数更改任何调优都必须符合业务场景，所以不要再谷歌什么什么调优了，对你的提升和业务环境的改善没有长久作用
#六、运维心态
##控制心态
很多rm -rf /data都在下班的前几分钟，都在烦躁的高峰，那么你还不打算控制下你的心态么？
有人说了，烦躁也要上班，可是你可以在烦躁的时候尽量避免处理关键数据环境。
越是有压力，越要冷静，不然会损失更多。
大多人都有rm -rf /data/mysql的经历，发现删除之后，那种心情你可以想象一下，可是如果没有备份，你急又有什么用，一般这种情况下，你就要冷静想下最坏打算了，对于MySQL来说，删除了物理文件，一部分表还会存在内存中，所以断开业务，但是不要关闭mysql数据库，这对恢复很有帮助，并使用dd复制硬盘，然后你再进行恢复。
当然了大多时候你就只能找数据恢复公司了。
试想一下，数据被删了，你各种操作，关闭数据库，然后修复，不但有可能覆盖文件，还找不到内存中的表了。
##对数据负责
生产环境不是儿戏，数据库也不是儿戏，一定要对数据负责。不备份的后果是非常严重的。
##追根究底
很多运维人员比较忙，遇到问题解决就不会再管了，记得去年一个客户的网站老是打不开，经过PHP代码报错。
发现是session和whos_online损坏，前任运维是通过repair修复的，我就也这样修复了，但是过了几个小时，又出现了。
反复三四次之后，我就去谷歌数据库表莫名损坏原因：一是MyISAM的bug，二是mysqlbug，三是MySQL在写入过程中
被kill，最后发现是内存不够用，导致OOM kill了mysqld进程。
并且没有swap分区，后台监控内存是够用的，最后升级物理内存解决。
##测试和生产环境
在重要操作之前一定要看自己所在的机器，尽量避免多开窗口。
原文链接：http://www.cnblogs.com/yihr/p/9593795.html
2019运维技能风向标
尼古拉斯 发表了文章 • 0 个评论 • 257 次浏览 • 2019-05-20 09:04
运维是一个融合多学科（网络、系统、开发、安全、应用架构、存储等）的综合性技术岗位，从最初的网络管理（网管）发展到现在的系统运维工程师、网络运维工程师、安全运维工程师、运维开发工程师等，可以看出，运维的分工一直在细化，并且对综合技能要求越来越高，可以看出，未来运 ...查看全部
运维是一个融合多学科（网络、系统、开发、安全、应用架构、存储等）的综合性技术岗位，从最初的网络管理（网管）发展到现在的系统运维工程师、网络运维工程师、安全运维工程师、运维开发工程师等，可以看出，运维的分工一直在细化，并且对综合技能要求越来越高，可以看出，未来运维的发展趋势是高、精、尖，高表示高度，精表示精通，尖表示尖端，也就是运维职场一定要站在一定的技术高度，在多个技术领域中，要精通某项技能，同时对尖端前沿技术一定要能掌控趋势。如果你想和更多运维技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
#运维职位的发展和趋势
根据不同的运维领域和技术面以及分工流程三个方面来了解下2019年运维职位的发展趋势。
##按领域来划分
##按技术切面来分
##按流程来划分
#系统运维技能图谱
系统运维是运维的基础，新的一年中，对基础运维技能要求也在提高，打好系统运维基础，才能深入学习后面的各种运维技能。
下图列出了系统运维要掌握的必备技能：
#Web运维技能图谱
Web运维是运维岗位中岗位最多的一个，薪资也相对较高，但需要掌握的知识点也比较多，新的技能要掌握，老的运维技能也不能丢，下图列出了Web运维要掌握的各种必备技能。
#大数据运维技能图谱
大数据从2017年开始逐渐走到生活的各个角落，2018年在逐渐落地，而在2019年，大数据依然火热，加上国家对大数据产业的扶持，大数据产业在新的一年岗位需求一定会更加大，因此掌握大数据运维技能，就走在了运维的前沿，下图列出了大数据运维要掌握的各种必备技能。
#容器运维技能图谱
容器的产生，是一次IT行业的革命，2015 年到 2016 年，是业界普遍认为的容器技术爆发的一年，短短一年多时间里，容器技术在中国大陆完成了从零星概念到烽火燎原的壮举。
时至今日，容器技术在国内大多数企业中落地已成为一种共识，而国内的生态系统，也呈现出了企业产品、开源社区和公有云齐头并进的良好局面。因此，2019年也是容器继续快速落地的一年，下图列出了大数据运维要掌握的各种必备技能。
#数据为王的时代
万丈高楼平地起，高楼稳不稳取决于地基是否扎实。运维数据便是运维管理这座高楼的地基。运维数据大致分为CMDB、日志、生产DB、知识库四个方面。
* CMDB中文是配置管理数据库，存储与管理企业IT架构中设备的各种配置信息，主要是IT资产管理信息。
* 日志数据保护了企业服务器上运行的各种系统产生的应用日志，系统日志、设备日志、数据库日志等数据，这部分数据是企业数据的核心。
* DB数据主要是所有IT系统的数据库信息，包括运维管理系统本身的数据库，数据库包含生产数据库、测试数据库、开发数据库三种类型。
* 知识库主要存储日常开发、测试、运维管理中发生的事件、问题以及一些经典问题的解决和常用的解决方案，主要起到运维管理辅助的功能。
对数据的维护和管理只管重要，特别是日志数据，对运维来说，通过日志可以比较准确全面地知道系统或是设备的运行情况，可以返查问题产生的原因，还原问题发生的整个过程。通过日志也可以提前预测系统可能要发生的问题或是故障，如系统安全日志，如果网络攻 击会在系统安全日志中有一定的体现。
下面简单介绍下，运维重点收集的日志数据有哪些部分以及用途。
##系统日志
系统日志主要指的是操作系统的日志，主要在/var/log下的各种日志信息。包含系统操作日志、系统安全日志、定时任务日志等。系统日志是运维管理安全模块中审计的重要依据。一般默认的操作系统日志不能满足要求，需要对系统的参数进行修改，如为history命令加上时间戳、IP，并且长久保留历史等功能。并且对日志文件进行处理，不允许用户进行清空命令，只能追加。
##应用日志
应用日志主要记录应用服务的健康运行情况以及业务操作的具体日志两部分。应用监控运行情况反应应用服务的健康状态，如果应用占用CPU或是内存过高或是忽高忽低不定，都可以通过分析应用日志结合业务操作日志得出结论。业务操作日志可以为业务审计提供主要依据。有一些系统喜欢把业务操作日志写到数据库中，这个也是需要注意的。不过不管在哪个地方，要求是不可缺少的，它为以后业务审计和问题返查提供依据。
##数据库日志
数据库日志主要反馈数据库的运行情况。通过监控和管理数据库的日志，及时了解数据库的运行情况，遇到问题及时解决等。可以通过数据库日志结合数据库系统自带的数据库如Oracle的系统视图v$开头，MySQL的performance_schema等。虽然数据库的一些信息不是存在日志中而是在数据库里面，但是也可以作为数据库日志的一部分进行管理和监控，已便我们及时知道数据库的监控状况，从而预防可能出现的问题。
##设备日志
设备日志一般是一个比较容易忽略的地方，但设备日志往往可以反映设备的运行情况。交换机故障，防火墙故障等设备故障都可能引起大面积的系统和服务故障。所以设备日志一定要收集，分析和监控预警。常用的设备日志有交换机日志、防火墙日志、网络安全设备日志等。
这么多的日志，运维要通过各种手段完成日志的收集、过滤分析、可视化展示，那么如何实现这些功能呢，方法很多，例如ELK集成套件（Elasticsearch，Logstash，Kibana）就可以轻松实现日志数据的实时收集、分析传输以及图形化展示。
* Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
* Logstash主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，Server端负责将收到的各节点日志进行过滤、修改等操作在一并发往Elasticsearch上去。
* Kibana也是一个开源和免费的工具，Kibana可以为Logstash和ElasticSearch提供的日志分析友好的Web界面，可以帮助汇总、分析和搜索重要数据日志。
另外，还有Filebeat可以替换Logstash作为日志收集工具，Filebeat隶属于Beats。目前Beats包含四种工具：
* Packetbeat（搜集网络流量数据）
* Topbeat（搜集系统、进程和文件系统级别的CPU和内存使用情况等数据）
* Filebeat（搜集文件数据）
* Winlogbeat（搜集Windows事件日志数据）
可以看到，Beats涵盖了所有收集日志数据的各个方面。
那么要如何使用ELK呢，根据日志量的不同，对应的ELK架构也不尽相同，看下面几个常见架构：
此架构主要是将Logstash部署在各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch再将数据以分片的形式压缩存储，并提供多种API供用户查询、操作。用户可以通过Kibana Web直观的对日志进行查询，并根据需求生成数据报表。
此架构的优点是搭建简单，易于上手。缺点是Logstash消耗系统资源比较大，运行时占用CPU和内存资源较高。另外，由于没有消息队列缓存，可能存在数据丢失的风险。此架构建议供初学者或数据量小的环境使用。
由此衍生出来了第二种架构：
此架构主要特点是引入了消息队列机制，位于各个节点上的Logstash Agent（一级Logstash，主要用来传输数据）先将数据传递给消息队列（常见的有Kafka、Redis等），接着，Logstash Server（二级Logstash，主要用来拉取消息队列数据，过滤并分析数据）将格式化的数据传递给Elasticsearch进行存储。最后，由Kibana将日志和数据呈现给用户。由于引入了Kafka（或者Redis）缓存机制，即使远端Logstash Server因故障停止运行，数据也不会丢失，因为数据已经被存储下来了。
这种架构适合于较大集群、数据量一般的应用环境，但由于二级Logstash要分析处理大量数据，同时Elasticsearch也要存储和索引大量数据，因此它们的负荷会比较重，解决的方法是将它们配置为集群模式，以分担负载。
此架构的优点在于引入了消息队列机制，均衡了网络传输，从而降低了网络闭塞尤其是丢失数据的可能性，但依然存在Logstash占用系统资源过多的问题，在海量数据应用场景下，可能会出现性能瓶颈。
最后，还有第三种架构：
这个架构是在上面第二个架构基础上改进而来的，主要是将前端收集数据的Logstash Agent换成了Filebeat，消息队列使用了Kafka集群，然后将Logstash和Elasticsearch都通过集群模式进行构建，此架构适合大型集群、海量数据的业务场景，它通过将前端Logstash Agent替换成Filebeat，有效降低了收集日志对业务系统资源的消耗。同时，消息队列使用Kafka集群架构，有效保障了收集数据的安全性和稳定性，而后端Logstash和Elasticsearch均采用集群模式搭建，从整体上提高了ELK系统的高效性、扩展性和吞吐量。
#用大数据思维做运维监控
大数据分析最早就来源于运维人的日志分析，到逐渐发展对各种业务的分析，人们发现这些数据蕴涵着非常大的价值，通过实时监测、跟踪研究对象在互联网上产生的海量行为数据，进行挖掘分析，揭示出规律性的东西，提出研究结论和对策。这就是大数据的用途。
同样，通过大数据分析，我们可以得到各种指标，例如：
而这些指标，刚好是运维特别需要的东西。通过大数据分析出的这些指标，可以解决如下方面的问题：
* 系统健康状况监控
* 查找故障根源
* 系统瓶颈诊断和调优
* 追踪安全相关问题
那么如何用大数据思维做运维呢，大数据架构上的一个思维就是：提供一个平台让运维方便解决这些问题， 而不是，让大数据平台去解决出现的问题。
基本的一个大数据运维架构是这样的：
对于运维的监控，利用大数据思维，需要分三步走：
* 获取需要的数据
* 过滤出异常数据并设置告警阀值
* 通过第三方监控平台进行告警
所有系统最可靠的就是日志输出，系统是不是正常，发生了什么情况，我们以前是出了问题去查日志，或者自己写个脚本定时去分析。现在这些事情都可以整合到一个已有的平台上，我们唯一要做的就是定义分析日志的的逻辑。
好啦，这就是今天要给大家介绍的2019核心运维技能啦，抓住时机，开始全新学习吧！2019，你的全新开始！！！
原文链接：你有一份2019运维技能风向标，请查收（作者：高俊峰）
#运维职位的发展和趋势
根据不同的运维领域和技术面以及分工流程三个方面来了解下2019年运维职位的发展趋势。
##按领域来划分
- 基础设施运维：IDC/网络运维、服务器/存储设备运维
- 系统运维：系统中间件运维、云计算平台运维
- 数据运维：数据库运维、大数据技术平台运维
- 应用运维：应用软件系统
- 云平台运维：公有云平台运维
- 容器运维：基于容器服务的运维
##按技术切面来分
- 安全运维
- 性能运维
- 数据运维
- 集成运维
##按流程来划分
- 构建/持续集成、发布
- 安装部署、升级、迁移、合并、扩展
- 配置、初始化、配置变更
- 备份、传输、恢复
- 日志、监控、预警
- 诊断排查、优化
#系统运维技能图谱
系统运维是运维的基础，新的一年中，对基础运维技能要求也在提高，打好系统运维基础，才能深入学习后面的各种运维技能。
下图列出了系统运维要掌握的必备技能：
#Web运维技能图谱
Web运维是运维岗位中岗位最多的一个，薪资也相对较高，但需要掌握的知识点也比较多，新的技能要掌握，老的运维技能也不能丢，下图列出了Web运维要掌握的各种必备技能。
#大数据运维技能图谱
大数据从2017年开始逐渐走到生活的各个角落，2018年在逐渐落地，而在2019年，大数据依然火热，加上国家对大数据产业的扶持，大数据产业在新的一年岗位需求一定会更加大，因此掌握大数据运维技能，就走在了运维的前沿，下图列出了大数据运维要掌握的各种必备技能。
#容器运维技能图谱
容器的产生，是一次IT行业的革命，2015 年到 2016 年，是业界普遍认为的容器技术爆发的一年，短短一年多时间里，容器技术在中国大陆完成了从零星概念到烽火燎原的壮举。
时至今日，容器技术在国内大多数企业中落地已成为一种共识，而国内的生态系统，也呈现出了企业产品、开源社区和公有云齐头并进的良好局面。因此，2019年也是容器继续快速落地的一年，下图列出了大数据运维要掌握的各种必备技能。
#数据为王的时代
万丈高楼平地起，高楼稳不稳取决于地基是否扎实。运维数据便是运维管理这座高楼的地基。运维数据大致分为CMDB、日志、生产DB、知识库四个方面。
* CMDB中文是配置管理数据库，存储与管理企业IT架构中设备的各种配置信息，主要是IT资产管理信息。
* 日志数据保护了企业服务器上运行的各种系统产生的应用日志，系统日志、设备日志、数据库日志等数据，这部分数据是企业数据的核心。
* DB数据主要是所有IT系统的数据库信息，包括运维管理系统本身的数据库，数据库包含生产数据库、测试数据库、开发数据库三种类型。
* 知识库主要存储日常开发、测试、运维管理中发生的事件、问题以及一些经典问题的解决和常用的解决方案，主要起到运维管理辅助的功能。
对数据的维护和管理只管重要，特别是日志数据，对运维来说，通过日志可以比较准确全面地知道系统或是设备的运行情况，可以返查问题产生的原因，还原问题发生的整个过程。通过日志也可以提前预测系统可能要发生的问题或是故障，如系统安全日志，如果网络攻 击会在系统安全日志中有一定的体现。
下面简单介绍下，运维重点收集的日志数据有哪些部分以及用途。
##系统日志
系统日志主要指的是操作系统的日志，主要在/var/log下的各种日志信息。包含系统操作日志、系统安全日志、定时任务日志等。系统日志是运维管理安全模块中审计的重要依据。一般默认的操作系统日志不能满足要求，需要对系统的参数进行修改，如为history命令加上时间戳、IP，并且长久保留历史等功能。并且对日志文件进行处理，不允许用户进行清空命令，只能追加。
##应用日志
应用日志主要记录应用服务的健康运行情况以及业务操作的具体日志两部分。应用监控运行情况反应应用服务的健康状态，如果应用占用CPU或是内存过高或是忽高忽低不定，都可以通过分析应用日志结合业务操作日志得出结论。业务操作日志可以为业务审计提供主要依据。有一些系统喜欢把业务操作日志写到数据库中，这个也是需要注意的。不过不管在哪个地方，要求是不可缺少的，它为以后业务审计和问题返查提供依据。
##数据库日志
数据库日志主要反馈数据库的运行情况。通过监控和管理数据库的日志，及时了解数据库的运行情况，遇到问题及时解决等。可以通过数据库日志结合数据库系统自带的数据库如Oracle的系统视图v$开头，MySQL的performance_schema等。虽然数据库的一些信息不是存在日志中而是在数据库里面，但是也可以作为数据库日志的一部分进行管理和监控，已便我们及时知道数据库的监控状况，从而预防可能出现的问题。
##设备日志
设备日志一般是一个比较容易忽略的地方，但设备日志往往可以反映设备的运行情况。交换机故障，防火墙故障等设备故障都可能引起大面积的系统和服务故障。所以设备日志一定要收集，分析和监控预警。常用的设备日志有交换机日志、防火墙日志、网络安全设备日志等。
这么多的日志，运维要通过各种手段完成日志的收集、过滤分析、可视化展示，那么如何实现这些功能呢，方法很多，例如ELK集成套件（Elasticsearch，Logstash，Kibana）就可以轻松实现日志数据的实时收集、分析传输以及图形化展示。
* Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
* Logstash主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，Server端负责将收到的各节点日志进行过滤、修改等操作在一并发往Elasticsearch上去。
* Kibana也是一个开源和免费的工具，Kibana可以为Logstash和ElasticSearch提供的日志分析友好的Web界面，可以帮助汇总、分析和搜索重要数据日志。
另外，还有Filebeat可以替换Logstash作为日志收集工具，Filebeat隶属于Beats。目前Beats包含四种工具：
* Packetbeat（搜集网络流量数据）
* Topbeat（搜集系统、进程和文件系统级别的CPU和内存使用情况等数据）
* Filebeat（搜集文件数据）
* Winlogbeat（搜集Windows事件日志数据）
可以看到，Beats涵盖了所有收集日志数据的各个方面。
那么要如何使用ELK呢，根据日志量的不同，对应的ELK架构也不尽相同，看下面几个常见架构：
此架构主要是将Logstash部署在各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch再将数据以分片的形式压缩存储，并提供多种API供用户查询、操作。用户可以通过Kibana Web直观的对日志进行查询，并根据需求生成数据报表。
此架构的优点是搭建简单，易于上手。缺点是Logstash消耗系统资源比较大，运行时占用CPU和内存资源较高。另外，由于没有消息队列缓存，可能存在数据丢失的风险。此架构建议供初学者或数据量小的环境使用。
由此衍生出来了第二种架构：
此架构主要特点是引入了消息队列机制，位于各个节点上的Logstash Agent（一级Logstash，主要用来传输数据）先将数据传递给消息队列（常见的有Kafka、Redis等），接着，Logstash Server（二级Logstash，主要用来拉取消息队列数据，过滤并分析数据）将格式化的数据传递给Elasticsearch进行存储。最后，由Kibana将日志和数据呈现给用户。由于引入了Kafka（或者Redis）缓存机制，即使远端Logstash Server因故障停止运行，数据也不会丢失，因为数据已经被存储下来了。
这种架构适合于较大集群、数据量一般的应用环境，但由于二级Logstash要分析处理大量数据，同时Elasticsearch也要存储和索引大量数据，因此它们的负荷会比较重，解决的方法是将它们配置为集群模式，以分担负载。
此架构的优点在于引入了消息队列机制，均衡了网络传输，从而降低了网络闭塞尤其是丢失数据的可能性，但依然存在Logstash占用系统资源过多的问题，在海量数据应用场景下，可能会出现性能瓶颈。
最后，还有第三种架构：
这个架构是在上面第二个架构基础上改进而来的，主要是将前端收集数据的Logstash Agent换成了Filebeat，消息队列使用了Kafka集群，然后将Logstash和Elasticsearch都通过集群模式进行构建，此架构适合大型集群、海量数据的业务场景，它通过将前端Logstash Agent替换成Filebeat，有效降低了收集日志对业务系统资源的消耗。同时，消息队列使用Kafka集群架构，有效保障了收集数据的安全性和稳定性，而后端Logstash和Elasticsearch均采用集群模式搭建，从整体上提高了ELK系统的高效性、扩展性和吞吐量。
#用大数据思维做运维监控
大数据分析最早就来源于运维人的日志分析，到逐渐发展对各种业务的分析，人们发现这些数据蕴涵着非常大的价值，通过实时监测、跟踪研究对象在互联网上产生的海量行为数据，进行挖掘分析，揭示出规律性的东西，提出研究结论和对策。这就是大数据的用途。
同样，通过大数据分析，我们可以得到各种指标，例如：
- 在业务层面，如团购业务每秒访问数，团购券每秒验券数，每分钟支付、创建订单等
- 在应用层面，每个应用的错误数，调用过程，访问的平均耗时，最大耗时，95线等
- 在系统资源层面：如CPU、内存、Swap、磁盘、Load、主进程存活等
- 在网络层面： 如丢包、ping存活、流量、TCP连接数等
而这些指标，刚好是运维特别需要的东西。通过大数据分析出的这些指标，可以解决如下方面的问题：
* 系统健康状况监控
* 查找故障根源
* 系统瓶颈诊断和调优
* 追踪安全相关问题
那么如何用大数据思维做运维呢，大数据架构上的一个思维就是：提供一个平台让运维方便解决这些问题， 而不是，让大数据平台去解决出现的问题。
基本的一个大数据运维架构是这样的：
对于运维的监控，利用大数据思维，需要分三步走：
* 获取需要的数据
* 过滤出异常数据并设置告警阀值
* 通过第三方监控平台进行告警
所有系统最可靠的就是日志输出，系统是不是正常，发生了什么情况，我们以前是出了问题去查日志，或者自己写个脚本定时去分析。现在这些事情都可以整合到一个已有的平台上，我们唯一要做的就是定义分析日志的的逻辑。
好啦，这就是今天要给大家介绍的2019核心运维技能啦，抓住时机，开始全新学习吧！2019，你的全新开始！！！
原文链接：你有一份2019运维技能风向标，请查收（作者：高俊峰）
运维监控的终极秘籍
尼古拉斯 发表了文章 • 0 个评论 • 1341 次浏览 • 2019-02-14 17:54
有很多文章多次提到白盒监控和黑盒监控，以及监控的四个黄金指标。关于白盒与黑盒监控的定义，这里不再赘述。一般来说，白盒与黑盒分别从内部和外部来监控系统的运行状况，例如机器存活、CPU内存使用率、业务日志、JMX等监控都属于白盒监控，而外部端口探活、HTTP探测以 ...查看全部
有很多文章多次提到白盒监控和黑盒监控，以及监控的四个黄金指标。关于白盒与黑盒监控的定义，这里不再赘述。一般来说，白盒与黑盒分别从内部和外部来监控系统的运行状况，例如机器存活、CPU内存使用率、业务日志、JMX等监控都属于白盒监控，而外部端口探活、HTTP探测以及端到端功能监控等则属于黑盒监控的范畴。
本文将主要从白盒监控的采集入手，解答关于新系统如何添加监控的问题。
图 1 黑盒与白盒监控
#监控指标的采集
配置监控时，我们首要面对的是监控数据如何采集的问题。一般我们可以把监控指标分为两类：基础监控和业务监控。
##基础监控
包括CPU、内存、磁盘、端口和进程等机器、网络的操作系统级别的信息。通常情况下，成熟的监控系统（例如开源的Prometheus、Zabbix等）均会提供基础监控项的采集能力，这里不做过多介绍。但需要注意的一点，机器级别的基础监控指标一般并不能代表服务的真实运行状况，例如单台实例的故障对一个设计合理的分布式系统来说并不会带来严重后果。所以只有结合业务相关监控指标，基础监控指标才有意义。
##业务监控
业务监控指标由业务系统内部的服务产生，一般能够真实反应业务运行状态。设计合理的系统一般都会提供相关监控指标供监控系统采集。监控数据的采集方法一般可以分为以下几大类：
* 日志：日志可以包含服务运行的方方面面，是重要的监控数据来源。例如，通过Nginx access日志可以统计出错误（5xx）、延迟（响应时间）和流量，结合已知的容量上限就可以计算出饱和度。一般除监控系统提供的日志采集插件外，如Rsyslog、Logstash、Filebeat、Flume等都是比较优秀的日志采集软件
* JMX：多数Java开发的服务均可由JMX接口输出监控指标。不少监控系统也有集成JMX采集插件，除此之外我们也可通过jmxtrans、jmxcmd工具进行采集
* REST：提供REST API来进行监控数据的采集，如Hadoop、ElasticSearch
* OpenMetrics：得益于Prometheus的流行，作为Prometheus的监控数据采集方案，OpenMetrics可能很快会成为未来监控的业界标准。目前绝大部分热门开源服务均有官方或非官方的exporter可供使用
* 命令行：一些服务提供本地的命令来输出监控指标
* 主动上报：对于采用PUSH模型的监控系统来说，服务可以采取主动上报的方式把监控指标push到监控系统，如Java服务可使用Metrics接口自定义sink输出。另外，运维也可以使用自定义的监控插件来完成监控的采集
* 埋点：埋点是侵入式的监控数据采集方式，其优点是其可以更灵活地为我们提供业务内部的监控指标，当然缺点也很明显：需要在代码层面动手脚（常常需要研发支持，成本较高）
* 其它方式：以上未涵盖的监控指标采集方式，例如ZooKeeper的四字命令，MySQL的show status命令
以上列出了几种常见的监控指标采集方法，在实际工作，如果没有现成的监控采集插件，则需要我们自行开发采集脚本。
#四个黄金指标
图 2 四个黄金指标
无论业务系统如何复杂，监控指标如何眼花缭乱，但万变不离其宗，监控的目的无非是为了解服务运行状况、发现服务故障和帮助定位故障原因。为了达成这个目的，Google SRE总结的监控四个黄金指标对我们添加监控具有非常重要的指导意义。图 2给出四个黄金指标所包含的主要监控指标，下面我们就这四个黄金指标分别展开说明，并给出一些监控项的采集实例。
##错误：错误是指当前系统发生的错误请求和错误率
错误是需要在添加监控时首要关注的指标。
在添加错误相关监控时，我们应该关注以下几个方面：
基础监控：宕机、磁盘（坏盘或文件系统错误）、进程或端口挂掉、网络丢包等故障
业务监控：
* 核心功能处理错误，每种系统都有特定的核心功能，比如HDFS的文件块读写、Zookeeper对Key的读写和修改操作
* 基础功能单元丢失或异常，这里的基础功能单元是指一个系统功能上的基本单位，例如HDFS的Block、Kafka的Message，这种基础数据的丢失一般都会对业务功能造成直接的影响
* Master故障，对于中心化的分布式系统来说，Master的健康状况都是重中之重。例如HDFS的NameNode、ZooKeeper的Leader，ElasticSearch的MasterNode
* 可用节点数，对于分布式系统来说，可用节点数也是非常重要的，比如ZooKeeper、ETCD等系统需要满足可用节点数大于不可用节点数才能保证功能的正常
注意：除白盒监控外，主要功能或接口、以及内部存在明显边界的功能模块和上游依赖模块，都应该添加黑盒端到端监控。
##延迟：服务请求所需时间
服务延迟的上升不仅仅体现在用户体验的下降，也有可能会导致请求堆积并最终演变为整个业务系统的雪崩。以下为延迟指标的主要关注点：
* 基础监控：IO等待、网络延迟
* 业务监控：业务相关指标主要需要关注核心功能的响应时长。比如ZooKeeper的延迟指标zk_avg_latency，ElasticSearch的索引、搜索延迟和慢查询
注意：与错误指标类似，白盒延迟指标通常仅能代表系统内部延迟，建议为主要功能或接口添加黑盒监控来采集端到端的延迟指标。
##流量：当前系统的流量
流量指标可以指系统层面的网络和磁盘IO，服务层面的QpS、PV和UV等数据。流量和突增或突减都可能预示着系统可能出现问题（攻击事件、系统故障……）。
* 基础监控：磁盘和网卡IO
* 业务监控：核心功能流量，例如通过QpS/PV/UV等通常能够代表Web服务的流量，而ElasticSearch的流量可用索引创建速率、搜索速率表示
##饱和度：用于衡量当前服务的利用率
更为通俗的讲，饱和度可以理解为服务的利用率，可以代表系统承受的压力。所以饱和度与流量息息相关，流量的上升一般也会导致饱和度的上升。通常情况下，每种业务系统都应该有各自的饱和度指标。在很多业务系统中，消息队列长度是一个比较重要的饱和度指标，除此之外CPU、内存、磁盘、网络等系统资源利用率也可以作为饱和度的一种体现方式。
基础监控：CPU、内存、磁盘和网络利用率、内存堆栈利用率、文件句柄数、TCP连接数等
业务监控：
* 基础功能单元使用率，大多数系统对其基础的功能单元都有其处理能力的上限，接近或达到该上限时可能会导致服务的错误、延迟增大。例如HDFS的Block数量上升会导致NameNode堆内存使用率上升，Kafka的Topics和Partitions的数量、Zookeeper的node数的上升都会对系统产生压力
* 消息队列长度，不少系统采用消息队列存放待处理数据，所以消息队列长度在一定程度上可以代表系统的繁忙程度。如ElasticSearch、HDFS等都有队列长度相关指标可供采集
#总结
以上总结了常见的监控指标采集方法，以及四个黄金指标所包含的常见内容。在实际工作中，不同的监控系统的设计多种多样，没有统一标准，并且不同的业务系统通常也有着特定的监控采集方法和不同的黄金指标定义，具体如何采集监控指标和添加告警都需要我们针对不同系统特点灵活应对。
原文链接：运维监控的终极秘籍，盘它！
本文将主要从白盒监控的采集入手，解答关于新系统如何添加监控的问题。
图 1 黑盒与白盒监控
#监控指标的采集
配置监控时，我们首要面对的是监控数据如何采集的问题。一般我们可以把监控指标分为两类：基础监控和业务监控。
##基础监控
包括CPU、内存、磁盘、端口和进程等机器、网络的操作系统级别的信息。通常情况下，成熟的监控系统（例如开源的Prometheus、Zabbix等）均会提供基础监控项的采集能力，这里不做过多介绍。但需要注意的一点，机器级别的基础监控指标一般并不能代表服务的真实运行状况，例如单台实例的故障对一个设计合理的分布式系统来说并不会带来严重后果。所以只有结合业务相关监控指标，基础监控指标才有意义。
##业务监控
业务监控指标由业务系统内部的服务产生，一般能够真实反应业务运行状态。设计合理的系统一般都会提供相关监控指标供监控系统采集。监控数据的采集方法一般可以分为以下几大类：
* 日志：日志可以包含服务运行的方方面面，是重要的监控数据来源。例如，通过Nginx access日志可以统计出错误（5xx）、延迟（响应时间）和流量，结合已知的容量上限就可以计算出饱和度。一般除监控系统提供的日志采集插件外，如Rsyslog、Logstash、Filebeat、Flume等都是比较优秀的日志采集软件
* JMX：多数Java开发的服务均可由JMX接口输出监控指标。不少监控系统也有集成JMX采集插件，除此之外我们也可通过jmxtrans、jmxcmd工具进行采集
* REST：提供REST API来进行监控数据的采集，如Hadoop、ElasticSearch
* OpenMetrics：得益于Prometheus的流行，作为Prometheus的监控数据采集方案，OpenMetrics可能很快会成为未来监控的业界标准。目前绝大部分热门开源服务均有官方或非官方的exporter可供使用
* 命令行：一些服务提供本地的命令来输出监控指标
* 主动上报：对于采用PUSH模型的监控系统来说，服务可以采取主动上报的方式把监控指标push到监控系统，如Java服务可使用Metrics接口自定义sink输出。另外，运维也可以使用自定义的监控插件来完成监控的采集
* 埋点：埋点是侵入式的监控数据采集方式，其优点是其可以更灵活地为我们提供业务内部的监控指标，当然缺点也很明显：需要在代码层面动手脚（常常需要研发支持，成本较高）
* 其它方式：以上未涵盖的监控指标采集方式，例如ZooKeeper的四字命令，MySQL的show status命令
以上列出了几种常见的监控指标采集方法，在实际工作，如果没有现成的监控采集插件，则需要我们自行开发采集脚本。
#四个黄金指标
图 2 四个黄金指标
无论业务系统如何复杂，监控指标如何眼花缭乱，但万变不离其宗，监控的目的无非是为了解服务运行状况、发现服务故障和帮助定位故障原因。为了达成这个目的，Google SRE总结的监控四个黄金指标对我们添加监控具有非常重要的指导意义。图 2给出四个黄金指标所包含的主要监控指标，下面我们就这四个黄金指标分别展开说明，并给出一些监控项的采集实例。
##错误：错误是指当前系统发生的错误请求和错误率
错误是需要在添加监控时首要关注的指标。
在添加错误相关监控时，我们应该关注以下几个方面：
基础监控：宕机、磁盘（坏盘或文件系统错误）、进程或端口挂掉、网络丢包等故障
业务监控：
* 核心功能处理错误，每种系统都有特定的核心功能，比如HDFS的文件块读写、Zookeeper对Key的读写和修改操作
* 基础功能单元丢失或异常，这里的基础功能单元是指一个系统功能上的基本单位，例如HDFS的Block、Kafka的Message，这种基础数据的丢失一般都会对业务功能造成直接的影响
* Master故障，对于中心化的分布式系统来说，Master的健康状况都是重中之重。例如HDFS的NameNode、ZooKeeper的Leader，ElasticSearch的MasterNode
* 可用节点数，对于分布式系统来说，可用节点数也是非常重要的，比如ZooKeeper、ETCD等系统需要满足可用节点数大于不可用节点数才能保证功能的正常
注意：除白盒监控外，主要功能或接口、以及内部存在明显边界的功能模块和上游依赖模块，都应该添加黑盒端到端监控。
##延迟：服务请求所需时间
服务延迟的上升不仅仅体现在用户体验的下降，也有可能会导致请求堆积并最终演变为整个业务系统的雪崩。以下为延迟指标的主要关注点：
* 基础监控：IO等待、网络延迟
* 业务监控：业务相关指标主要需要关注核心功能的响应时长。比如ZooKeeper的延迟指标zk_avg_latency，ElasticSearch的索引、搜索延迟和慢查询
注意：与错误指标类似，白盒延迟指标通常仅能代表系统内部延迟，建议为主要功能或接口添加黑盒监控来采集端到端的延迟指标。
##流量：当前系统的流量
流量指标可以指系统层面的网络和磁盘IO，服务层面的QpS、PV和UV等数据。流量和突增或突减都可能预示着系统可能出现问题（攻击事件、系统故障……）。
* 基础监控：磁盘和网卡IO
* 业务监控：核心功能流量，例如通过QpS/PV/UV等通常能够代表Web服务的流量，而ElasticSearch的流量可用索引创建速率、搜索速率表示
##饱和度：用于衡量当前服务的利用率
更为通俗的讲，饱和度可以理解为服务的利用率，可以代表系统承受的压力。所以饱和度与流量息息相关，流量的上升一般也会导致饱和度的上升。通常情况下，每种业务系统都应该有各自的饱和度指标。在很多业务系统中，消息队列长度是一个比较重要的饱和度指标，除此之外CPU、内存、磁盘、网络等系统资源利用率也可以作为饱和度的一种体现方式。
基础监控：CPU、内存、磁盘和网络利用率、内存堆栈利用率、文件句柄数、TCP连接数等
业务监控：
* 基础功能单元使用率，大多数系统对其基础的功能单元都有其处理能力的上限，接近或达到该上限时可能会导致服务的错误、延迟增大。例如HDFS的Block数量上升会导致NameNode堆内存使用率上升，Kafka的Topics和Partitions的数量、Zookeeper的node数的上升都会对系统产生压力
* 消息队列长度，不少系统采用消息队列存放待处理数据，所以消息队列长度在一定程度上可以代表系统的繁忙程度。如ElasticSearch、HDFS等都有队列长度相关指标可供采集
#总结
以上总结了常见的监控指标采集方法，以及四个黄金指标所包含的常见内容。在实际工作中，不同的监控系统的设计多种多样，没有统一标准，并且不同的业务系统通常也有着特定的监控采集方法和不同的黄金指标定义，具体如何采集监控指标和添加告警都需要我们针对不同系统特点灵活应对。
原文链接：运维监控的终极秘籍，盘它！
360互联网技术训练营第九期——360容器技术解密与实践 火热报名中！
HULK 发表了文章 • 0 个评论 • 894 次浏览 • 2018-04-03 10:56
随着服务端架构的飞速发展，传统的部署和维护方式已经不足以满足业务的飞速增长，容器做为目前最炙手可热的技术，为开发和运维人员带来了极大的便捷性。
在第九期360互联网技术训练营中，360的精英攻城狮们就来为大家讲解容器技术在360的应用与实践，看容 ...查看全部
随着服务端架构的飞速发展，传统的部署和维护方式已经不足以满足业务的飞速增长，容器做为目前最炙手可热的技术，为开发和运维人员带来了极大的便捷性。
在第九期360互联网技术训练营中，360的精英攻城狮们就来为大家讲解容器技术在360的应用与实践，看容器变利器，快速解决业务痛点。
同时更有hyper公司的技术大牛为我们带来相关的技术分享。
报名地址：http://www.huodongxing.com/event/2431945121700
现场还有小礼品哦！
在第九期360互联网技术训练营中，360的精英攻城狮们就来为大家讲解容器技术在360的应用与实践，看容器变利器，快速解决业务痛点。
同时更有hyper公司的技术大牛为我们带来相关的技术分享。
报名地址：http://www.huodongxing.com/event/2431945121700
现场还有小礼品哦！
怎样才是真正的灰度发布？
灵雀云 发表了文章 • 0 个评论 • 2342 次浏览 • 2018-01-31 11:23
究竟什么才是灰度发布其实并没有一个严格的标准，因为这个东西不是黑的也不是白的是个中间过渡地带，这类的东西定义都会比较麻烦。由于工作的原因看到好多友商所谓的灰度发布产品，有意思的是他们实现的是完全不一样的功能，对外都说自己是灰度发布。我看到的有三种： ...查看全部
究竟什么才是灰度发布其实并没有一个严格的标准，因为这个东西不是黑的也不是白的是个中间过渡地带，这类的东西定义都会比较麻烦。由于工作的原因看到好多友商所谓的灰度发布产品，有意思的是他们实现的是完全不一样的功能，对外都说自己是灰度发布。我看到的有三种：
1. 更新过程可以暂停，停在一个既有新版本又有旧版本的状态，然后选择升级或者回滚
2. 支持流量比例分配，可以把百分之几的流量分配给一个服务，剩下的给另一个服务
3. 支持 url 路径流量分配，一个路径下的流量给一个服务，另一个路径流量给另一个服务
那究竟哪个才能算是灰度发布呢？抛开具体的技术实现，让我们从需求的角度来考虑一下为什么要有灰度发布？灰度发布究竟是要做什么？从目的出发再来看技术实现就会清晰很多。
既然要灰度就是不希望所有人都看到，就是为了控制影响范围，之所以要做这种限制就说明发布的人心里对这个发布的版本就是不确定的，害怕影响范围太大风险不可控。也就是说这个风险因素在开发和测试环境都没有办法控制，只能在生产环境来观察，那究竟是怎样的因素会导致必须要上线观察而不是在开发测试环节来解决呢？主要有从运维和产品两大方面的考量因素。
从运维的角度讲，任何一次上线都是有风险的，或者有一些步骤的遗漏，流程的不规范，或者有一些隐藏的代码 bug都会导致线上的不稳定。控制风险的办法就是小批量上线，验证之后在全部更新。此外一些稳定性和性能的问题在开发测试环境很难复现，因此这一类的修复和功能只能到生产环境来验证，同样由于效果的未知也不可能全量更新。再有一些大的重构，比如编程语言的变化，框架的变化，基础库的更新，操作系统的更新都会有未知的影响，而这些影响也需要生产的检验。
从产品的角度讲，有一些产品设计，交互，界面展现形式都不是坐在办公室里拍桌子就可以定出最佳实践的。产品经理的视角和用户的视角是不同的，即使是产品经理之间的风格，偏好也是不一致的。小到按钮的顺序，弹框展示的位置，大到页面整体的布局，广告位的展示策略，究竟用哪种设计更好并没有理论上的最佳实践。而这种情况就需要大家分别作出自己的方案，去线上收集真实的用户数据作对比。也就是硅谷里常说的 A/B testing，也可以归到灰度发布的范畴。本质上就是基于数据驱动来作抉择，在用户的投票中选择哪种方案，而不是传统的看谁嗓门大会拍桌子，看谁官大来做决策。
了解了需求，我们就很容易推导出所有人都在说的灰度发布真正是什么了
1. 精确的流量分发控制
这是一切的核心，从运维风险控制的角度，需要把受影响的流量控制在一个精确的范围内，在上线前就知道哪部分用户会有问题，而不是真出问题谁受到影响都不知道。一个常见场景是新版本只让公司内部的员工能访问到，再一个市，一个省的一点点推上去。从产品角度看要做 A/B test，就需要控制测试样本，哪些用户是 A 版本，哪些用户是 B 版本，在发布后应该就是固定的，而不是一个用户一会儿访问 A，一会儿访问 B。而传统的负载均衡器策略只能做到粗犷的比例分配，并没有细粒度的流量规则控制。而一个理想的灰度发布系统应该有很细粒度的流量规则，比如匹配 android 用户，匹配某个地区的用户，甚至能组合多种条件匹配到特定的人群。
2. 监控系统的支撑
流量精确分配只是第一步，接下来更重要的是获得多个版本的关键指标。对运维来说可能是看错误率，吞吐量，延迟，cpu 内存消耗这些系统层面指标。对于产品来说可能是要看点击率，pv，uv 等业务指标的变化。这些都需要能把数据收集并作展示，来方便后续决策：全量推还是回滚？使用方案 A 还是 B？不然的话灰度发布带来不了更多业务方面的促进，也不能帮你更好的了解业务的状态和用户行为。
3. 灵活的发布系统
从上面的介绍可以看出灰度发布并不是个短暂的过程，可能会持续很久。例如某个重大的框架或者系统更新可能会持续很久，有可能整个服务在几个月内都是新旧并存，甚至有可能需要两个版本分别各自迭代。而从产品的角度来看可能就会更灵活，很有可能线上有五六个方案都在收集数据，每天有了一些新想法都要上一些小版本看效果，每个版本上线后可能都要再各自做优化调整观察效果。这种情况可能线上就永远不会有一个统一的版本灰度反而是个常态来应对不断变化的需求和挑战。而发布系统也需要做相应的调整，不在把每个服务看成一个单一版本的运行体，只在更新的短时间内出现多版本共存，只允许全量推和回滚这种粗粒度策略。而是应该将多版本共存看成常态，允许每个版本各自迭代，版本之间又能区分对应的监控日志信息，这样灵活的发布系统才能配合灵活的灰度策略。
说了这么写灰度系统要做的事情其实就是流量控制和数据收集，来控制风险并帮助产品做决策。再看一下最开始提出的三个所谓的灰度发布：更新过程可以暂停，流量比例分配，url分流。它们充其量也只是做到了流量精确分配的某几个特殊情况，而且还都是不很精确的分配。而如果结合使用场景就会发现，这几种在实际中是很难用起来的，因为没有流量的精确控制很难控制风险范围，如果风险都不可控，那还要灰度发布干什么呢？更不要提后面的监控数据收集和灵活的发布了。
所以说一个真实好用的发布系统是十分复杂的，绝对不是页面上点两三下就可以完成的，而后面的实现更需要一整套体系来支撑。如果你想打造一个灰度发布系统，希望这篇文章能对你有所启发。
自动化运维为什么是必须的？
goodrain 发表了文章 • 0 个评论 • 1653 次浏览 • 2017-08-31 12:37
运维团队负责最大限度提高效率、降低成本，这也意味着他们往往承受着巨大的压力，需要解决在不增加员工的情况下，最大限度产出价值的问题。
【烧脑式Kubernetes实战训练营】本次培训理论结合实践，主要包括：Kubernetes架构和资源 ...查看全部
运维团队负责最大限度提高效率、降低成本，这也意味着他们往往承受着巨大的压力，需要解决在不增加员工的情况下，最大限度产出价值的问题。
【烧脑式Kubernetes实战训练营】本次培训理论结合实践，主要包括：Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。
达成这样的要求，仅靠人工是很难的，采用自动化运维则是靠谱的选择。我们不妨总结一下自动化运维带来的好处——
消除无效率 - 运维工作的手动工作，如果可以实现自动化，将显著提升效率水平。
减少错误 - 即使最谨慎的人，也会犯错，尤其是面对着重复性工作。通过运维自动化工具来完成这样的工作，结果是显而易见的，错误率将大大降低。
最大化员工使用 - 通过运维自动化，运维专家们的经历可以集中在更复杂、更有战略意义的业务问题上。同时也降低了雇佣更多员工来应对工作量增加的需求。同样一批人，有自动化运维，就有更大的能量来创造价值。
提高满意度水平 - 自动化运维工具帮助IT运维，为内部和外部客户提供高水平支持。无论是通过提供自助服务选项，还是大幅缩短时间（最多达90％）来减少联系和等待服务台的需求，自动化运维让我们可以更好得拥抱SLA。
降低成本 - 系统中断、人为错误、重复工作，会导致不菲的费用和代价，而自动化运维几乎可以将这些成本完全消除。
为了获得最佳的结果，运维应该将自动化最为其“最佳实践”的一部分，尽可能多的实施自动化流程。除了成本和费用上的减少，无数例子证明，其业务敏捷性和整体服务提供也将呈指数级增长。
Source
```
好雨云帮ACP · 自动化运维
https://www.goodrain.com/autoOM.html
自动化运维把周期性、重复性、规律性的工作交给平台去处理，通过标准化、自动化、架构化、过程优化来降低运维成本、提高运维效率。云帮ACP提供从基础架构到应用的全栈自动化运维，安全、稳定、强大。
```
【烧脑式Kubernetes实战训练营】本次培训理论结合实践，主要包括：Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。
达成这样的要求，仅靠人工是很难的，采用自动化运维则是靠谱的选择。我们不妨总结一下自动化运维带来的好处——
消除无效率 - 运维工作的手动工作，如果可以实现自动化，将显著提升效率水平。
减少错误 - 即使最谨慎的人，也会犯错，尤其是面对着重复性工作。通过运维自动化工具来完成这样的工作，结果是显而易见的，错误率将大大降低。
最大化员工使用 - 通过运维自动化，运维专家们的经历可以集中在更复杂、更有战略意义的业务问题上。同时也降低了雇佣更多员工来应对工作量增加的需求。同样一批人，有自动化运维，就有更大的能量来创造价值。
提高满意度水平 - 自动化运维工具帮助IT运维，为内部和外部客户提供高水平支持。无论是通过提供自助服务选项，还是大幅缩短时间（最多达90％）来减少联系和等待服务台的需求，自动化运维让我们可以更好得拥抱SLA。
降低成本 - 系统中断、人为错误、重复工作，会导致不菲的费用和代价，而自动化运维几乎可以将这些成本完全消除。
为了获得最佳的结果，运维应该将自动化最为其“最佳实践”的一部分，尽可能多的实施自动化流程。除了成本和费用上的减少，无数例子证明，其业务敏捷性和整体服务提供也将呈指数级增长。
Source
```
好雨云帮ACP · 自动化运维
https://www.goodrain.com/autoOM.html
自动化运维把周期性、重复性、规律性的工作交给平台去处理，通过标准化、自动化、架构化、过程优化来降低运维成本、提高运维效率。云帮ACP提供从基础架构到应用的全栈自动化运维，安全、稳定、强大。
```
自动化运维要点
goodrain 发表了文章 • 0 个评论 • 2307 次浏览 • 2017-08-29 13:24
Source
什么是自动化运维
自动化运维是指将IT运维中日常的、大量的重复性工作自动化，把过去的手工执行转为自动化操作。自动化是IT运维工作的升华，自动化运维不单纯是一个维护过程，更是一个管理的提升过程， ...查看全部
Source
什么是自动化运维
自动化运维是指将IT运维中日常的、大量的重复性工作自动化，把过去的手工执行转为自动化操作。自动化是IT运维工作的升华，自动化运维不单纯是一个维护过程，更是一个管理的提升过程，是IT运维的最高层次，也是未来的发展趋势。
传统运维管理方式存在的问题
目前许多企业的IT运维已经实现从人工运维到计算机管理，但延展咨询在同客户的交流中发现其中很多企业的IT运维管理还只是处在「半自动化」的运维状态。因为这种IT运维仍然是等到IT故障出现后再由运维人员采取相应的补救措施。这些传统式被动、孤立、半自动式的IT运维管理模式经常让IT部门疲惫不堪，主要表现在以下三个方面:
* 运维人员被动、效率低
在IT运维过程中，只有当事件已经发生并已造成业务影响时才能发现和着手处理，这种被动「救火」不但使IT运维人员终日忙碌，也使IT运维本身质量很难提高，导致IT部门和业务部门对IT运维的服务满意度都不高。目前绝大多数的企业IT运维人员日常大部分时间和精力是处理一些简单重复的问题，而且由于故障预警机制不完善，往往是故障发生后或报警后才会进行处理，,使到IT运维人员的工作经常是处于被动「救火」的状态，不但事倍功半而且常常会出现恶性连锁反应。
* 缺乏一套高效的IT运维机制
目前许多企业在IT运维管理过程中缺少自动化的运维管理模式，也没有明确的角色定义和责任划分，使到问题出现后很难快速、准确地找到根本原因，无法及时地找到相应的人员进行修复和处理，或者是在问题找到后缺乏流程化的故障处理机制，而在处理问题时不但欠缺规范化的解决方案，也缺乏全面的跟踪记录。
* 缺乏高效的IT运维技术工具
随着信息化建设的深入，企业IT系统日趋复杂，林林总总的网路设备、伺服器、中间件、业务系统等让IT运维人员难以从容应对，即使加班加点地维护、部署、管理也经常会因设备出现故障而导致业务的中断，严重影响企业的正常运转。出现这些问题部分原因是企业缺乏事件监控和诊断工具等IT运维技术工具，因为在没有高效的技术工具的支持下故障事件很难得到主动、快速处理。
自动化运维迫在眉睫
尽管IT运维管理的技术在不断进步，但实际上很多IT运维人员并没有真正解脱出来，原因在于目前的技术虽然能够获取IT设备、伺服器、网路流量，甚至资料库的警告信息，但成千上万条警告信息堆积在一起更本没法判断问题的根源在哪里。另外，目前许多企业的更新管理绝大多数工作都是手工操作的。即使一个简单的系统变更或更新往往都需要运维人员逐一登录每台设备进行手工变更，当设备数量达至成百上千时，其工作量之大可想而知。而这样的变更和检查操作在IT运维中往往每天都在进行，占用了大量的运维资源。因此，实现运维管理工作的自动化对企业来说已迫在眉睫。
现在随着IT运维管理工作的复杂度和难度的大大增加，仅靠过去几个「运维英雄」或「技术大拿」来包打天下已经行不通了，企业开始需要运用专业化、标准化和流程化的手段来实现运维工作的自动化管理。因为通过自动化监控系统能及时发现故障隐患，主动的告诉用户需要关注的资源，以达到防患于未然。例如，全天候自动检测与及时报警能实现IT运维的「全天候无人值守」，大大降低IT运维人员的工作负担。而且，通过自动化诊断能最大限度地减少维修时间,提高服务质量。因此, 对于越来越复杂的IT运维来说，将纯粹的人工操作变为一定程度的自动化管理是一个重要发展趋势。
首先，IT运维流程自动化能够提高流程的可控性，可以基于业务需求来制定个性化的流程，使企业领导有机会看见他们的业务流程，对企业流程有一个深刻的分析和理解，进而改造和优化流程。
其次，IT运维流程的自动化能提高透明度。因为随着业务需求的变化可能会有多个版本出现，手工流程的不透明将会给流程定制和优化带来相当大的困难，而自动化流程可以使用户能够一目了然的看到整个流程的各个节点运转情况，自动化工具潜移默化地提升业务保障能力。
再者，运维系统实行了自动化监控以后，通过工具自动监控对人的工作是一种减负，也是一种降低成本的表现。
自动化运维管理的具体内容
IT运维已经在风风雨雨中走过了十几个春秋，如今它正以一种全新的姿态摆在我们面前--自动化，这是IT技术发展的必然结果。现在IT系统的复杂性已经客观上要求IT运维必须能够实现数字化、自动化维护。所谓IT运维管理的自动化是指通过将日常IT运维中大量的重复性工作（小到简单的日常检查、配置变更和软体安装，大到整个变更流程的组织调度）由过去的手工执行转为自动化操作，从而减少乃至消除运维中的延迟，实现「零延时」的IT运维。
简单的说，自动化运维是指基于流程化的框架，将事件与IT流程相关联，一旦被监控系统发生性能超标或宕机，会触发相关事件以及事先定义好的流程，可自动启动故障响应和恢复机制。自动化工作平台还可帮助IT运维人员完成日常的重复性工作(如备份、杀毒等)，提高IT运维效率。同时，IT运维的自动化还要求能够预测故障、在故障发生前能够报警，让IT运维人员把故障消除在发生前，将所产生损失减到最低。
自动化运维的工具
对于企业来说，要特别关注两类自动化工具：一是IT运维监控和诊断优化工具；二是运维流程自动化工具。这两类工具主要应用于：
* 监控自动化，是指对重要的IT设备实施主动式监控,如路由器、交换机、防火墙等；
* 配置变更检测自动化，是指IT设备配置参数一旦发生变化，将触发变更流程转给相关技术人员进行确认,通过自动检测协助IT运维人员发现和维护配置。
* 维护事件提醒自动化,是指通过对IT设备和应用活动的时时监控,当发生异常事件时系统自动启动报警和响应机制,第一事件通知相关责任人。
* 系统健康检测自动化,是指定期自动地对IT设备硬体和应用系统进行健康巡检,配合IT运维团队实施对系统的健康检查和监控。
* 维护报告生成自动化,是指定期自动的对系统做日志的收集分析,记录系统运行状况,并通过阶段性的监控、分析和总结,定时提供IT运维的可用性、性能、系统资源利用状况分析报告。
```
好雨云帮ACP · 自动化运维
https://www.goodrain.com/autoOM.html
自动化运维把周期性、重复性、规律性的工作交给平台去处理，通过标准化、自动化、架构化、过程优化来降低运维成本、提高运维效率。云帮ACP提供从基础架构到应用的全栈自动化运维，安全、稳定、强大。
```
建立高效自动化运维管理的步骤
* 建立自动化运维管理平台
自动化运维管理建设的第一步是要先建立IT运维的自动化监控和管理平台。通过监控工具实现对用户操作规范的约束和对IT资源进行实时监控，包括伺服器、资料库、中间件、存储备份、网路、安全、机房、业务应用和客户端等内容，通过自动监控管理平台实现故障或问题综合处理和集中管理。例如，在自定义周期内进行自动触发完成对IT运维的例行巡检，形成检查报告。包括自动运行维护，以完成对系统补丁的同步分发与升级、数据备份、病毒查杀等工作。
* 建立故障事件自动触发流程，提高故障处理效率
所有IT设备在遇到问题时要会自动报警，无论是系统自动报警还是使用人员报的故障，应以红色标识显示在运维屏幕上。然后IT运维人员只需要按照相关知识库的数据，一步一步操作就可以。因此，企业需要事先建立自动工单式流程管理，当设备或软体发生异常或超出预警指标时会触发相关的事件，同时触发相关工单处理流程给相关IT运维人员。 IT运维人员必须在指定时间内完成流程所规定的环节与工作，以提高IT运维响应问题的效率。
* 建立规范的事件跟踪流程，强化运维执行力度
自动化运维管理建设时，首先需要建立故障和事件处理跟踪流程，利用表格工具等记录故障及其处理情况，以建立运维日志，并定期回顾从中辨识和发现问题的线索和根源。事实上许多实践也证明，建立每种事件的规范化处理和跟踪指南，可以减少IT运维操作的随意性和强化运维的执行力度，在很大程度上可降低故障发生的概率。同时，用户还应可以通过自助服务台、电话服务台等随时追踪该故障请求的处理状态。
* 设立IT运维关键流程，引入优先处理原则
设立IT运维关键流程，引入优先处理原则是指要求CIO定义出IT运维的每个关键流程，不仅仅是定义流程是什么，还包括要指出每个关键流程对企业有什么影响和意义。同时，在设置自动化流程时还需要引入优先处理原则，例行的事按常规处理，特别事件要按优先顺序次序处理，也就是把事件细分为例行事件和例外关键事件。
总之，实现IT运维的自动化管理是指通过将IT运维中日常的、大量的重复性工作自动化，把过去的手工执行转为自动化操作。自动化是IT运维工作的升华，自动化运维不单纯是一个维护过程，更是一个管理的提升过程，是IT运维的最高层次，也是未来的发展趋势。
什么是自动化运维
自动化运维是指将IT运维中日常的、大量的重复性工作自动化，把过去的手工执行转为自动化操作。自动化是IT运维工作的升华，自动化运维不单纯是一个维护过程，更是一个管理的提升过程，是IT运维的最高层次，也是未来的发展趋势。
传统运维管理方式存在的问题
目前许多企业的IT运维已经实现从人工运维到计算机管理，但延展咨询在同客户的交流中发现其中很多企业的IT运维管理还只是处在「半自动化」的运维状态。因为这种IT运维仍然是等到IT故障出现后再由运维人员采取相应的补救措施。这些传统式被动、孤立、半自动式的IT运维管理模式经常让IT部门疲惫不堪，主要表现在以下三个方面:
* 运维人员被动、效率低
在IT运维过程中，只有当事件已经发生并已造成业务影响时才能发现和着手处理，这种被动「救火」不但使IT运维人员终日忙碌，也使IT运维本身质量很难提高，导致IT部门和业务部门对IT运维的服务满意度都不高。目前绝大多数的企业IT运维人员日常大部分时间和精力是处理一些简单重复的问题，而且由于故障预警机制不完善，往往是故障发生后或报警后才会进行处理，,使到IT运维人员的工作经常是处于被动「救火」的状态，不但事倍功半而且常常会出现恶性连锁反应。
* 缺乏一套高效的IT运维机制
目前许多企业在IT运维管理过程中缺少自动化的运维管理模式，也没有明确的角色定义和责任划分，使到问题出现后很难快速、准确地找到根本原因，无法及时地找到相应的人员进行修复和处理，或者是在问题找到后缺乏流程化的故障处理机制，而在处理问题时不但欠缺规范化的解决方案，也缺乏全面的跟踪记录。
* 缺乏高效的IT运维技术工具
随着信息化建设的深入，企业IT系统日趋复杂，林林总总的网路设备、伺服器、中间件、业务系统等让IT运维人员难以从容应对，即使加班加点地维护、部署、管理也经常会因设备出现故障而导致业务的中断，严重影响企业的正常运转。出现这些问题部分原因是企业缺乏事件监控和诊断工具等IT运维技术工具，因为在没有高效的技术工具的支持下故障事件很难得到主动、快速处理。
自动化运维迫在眉睫
尽管IT运维管理的技术在不断进步，但实际上很多IT运维人员并没有真正解脱出来，原因在于目前的技术虽然能够获取IT设备、伺服器、网路流量，甚至资料库的警告信息，但成千上万条警告信息堆积在一起更本没法判断问题的根源在哪里。另外，目前许多企业的更新管理绝大多数工作都是手工操作的。即使一个简单的系统变更或更新往往都需要运维人员逐一登录每台设备进行手工变更，当设备数量达至成百上千时，其工作量之大可想而知。而这样的变更和检查操作在IT运维中往往每天都在进行，占用了大量的运维资源。因此，实现运维管理工作的自动化对企业来说已迫在眉睫。
现在随着IT运维管理工作的复杂度和难度的大大增加，仅靠过去几个「运维英雄」或「技术大拿」来包打天下已经行不通了，企业开始需要运用专业化、标准化和流程化的手段来实现运维工作的自动化管理。因为通过自动化监控系统能及时发现故障隐患，主动的告诉用户需要关注的资源，以达到防患于未然。例如，全天候自动检测与及时报警能实现IT运维的「全天候无人值守」，大大降低IT运维人员的工作负担。而且，通过自动化诊断能最大限度地减少维修时间,提高服务质量。因此, 对于越来越复杂的IT运维来说，将纯粹的人工操作变为一定程度的自动化管理是一个重要发展趋势。
首先，IT运维流程自动化能够提高流程的可控性，可以基于业务需求来制定个性化的流程，使企业领导有机会看见他们的业务流程，对企业流程有一个深刻的分析和理解，进而改造和优化流程。
其次，IT运维流程的自动化能提高透明度。因为随着业务需求的变化可能会有多个版本出现，手工流程的不透明将会给流程定制和优化带来相当大的困难，而自动化流程可以使用户能够一目了然的看到整个流程的各个节点运转情况，自动化工具潜移默化地提升业务保障能力。
再者，运维系统实行了自动化监控以后，通过工具自动监控对人的工作是一种减负，也是一种降低成本的表现。
自动化运维管理的具体内容
IT运维已经在风风雨雨中走过了十几个春秋，如今它正以一种全新的姿态摆在我们面前--自动化，这是IT技术发展的必然结果。现在IT系统的复杂性已经客观上要求IT运维必须能够实现数字化、自动化维护。所谓IT运维管理的自动化是指通过将日常IT运维中大量的重复性工作（小到简单的日常检查、配置变更和软体安装，大到整个变更流程的组织调度）由过去的手工执行转为自动化操作，从而减少乃至消除运维中的延迟，实现「零延时」的IT运维。
简单的说，自动化运维是指基于流程化的框架，将事件与IT流程相关联，一旦被监控系统发生性能超标或宕机，会触发相关事件以及事先定义好的流程，可自动启动故障响应和恢复机制。自动化工作平台还可帮助IT运维人员完成日常的重复性工作(如备份、杀毒等)，提高IT运维效率。同时，IT运维的自动化还要求能够预测故障、在故障发生前能够报警，让IT运维人员把故障消除在发生前，将所产生损失减到最低。
自动化运维的工具
对于企业来说，要特别关注两类自动化工具：一是IT运维监控和诊断优化工具；二是运维流程自动化工具。这两类工具主要应用于：
* 监控自动化，是指对重要的IT设备实施主动式监控,如路由器、交换机、防火墙等；
* 配置变更检测自动化，是指IT设备配置参数一旦发生变化，将触发变更流程转给相关技术人员进行确认,通过自动检测协助IT运维人员发现和维护配置。
* 维护事件提醒自动化,是指通过对IT设备和应用活动的时时监控,当发生异常事件时系统自动启动报警和响应机制,第一事件通知相关责任人。
* 系统健康检测自动化,是指定期自动地对IT设备硬体和应用系统进行健康巡检,配合IT运维团队实施对系统的健康检查和监控。
* 维护报告生成自动化,是指定期自动的对系统做日志的收集分析,记录系统运行状况,并通过阶段性的监控、分析和总结,定时提供IT运维的可用性、性能、系统资源利用状况分析报告。
```
好雨云帮ACP · 自动化运维
https://www.goodrain.com/autoOM.html
自动化运维把周期性、重复性、规律性的工作交给平台去处理，通过标准化、自动化、架构化、过程优化来降低运维成本、提高运维效率。云帮ACP提供从基础架构到应用的全栈自动化运维，安全、稳定、强大。
```
建立高效自动化运维管理的步骤
* 建立自动化运维管理平台
自动化运维管理建设的第一步是要先建立IT运维的自动化监控和管理平台。通过监控工具实现对用户操作规范的约束和对IT资源进行实时监控，包括伺服器、资料库、中间件、存储备份、网路、安全、机房、业务应用和客户端等内容，通过自动监控管理平台实现故障或问题综合处理和集中管理。例如，在自定义周期内进行自动触发完成对IT运维的例行巡检，形成检查报告。包括自动运行维护，以完成对系统补丁的同步分发与升级、数据备份、病毒查杀等工作。
* 建立故障事件自动触发流程，提高故障处理效率
所有IT设备在遇到问题时要会自动报警，无论是系统自动报警还是使用人员报的故障，应以红色标识显示在运维屏幕上。然后IT运维人员只需要按照相关知识库的数据，一步一步操作就可以。因此，企业需要事先建立自动工单式流程管理，当设备或软体发生异常或超出预警指标时会触发相关的事件，同时触发相关工单处理流程给相关IT运维人员。 IT运维人员必须在指定时间内完成流程所规定的环节与工作，以提高IT运维响应问题的效率。
* 建立规范的事件跟踪流程，强化运维执行力度
自动化运维管理建设时，首先需要建立故障和事件处理跟踪流程，利用表格工具等记录故障及其处理情况，以建立运维日志，并定期回顾从中辨识和发现问题的线索和根源。事实上许多实践也证明，建立每种事件的规范化处理和跟踪指南，可以减少IT运维操作的随意性和强化运维的执行力度，在很大程度上可降低故障发生的概率。同时，用户还应可以通过自助服务台、电话服务台等随时追踪该故障请求的处理状态。
* 设立IT运维关键流程，引入优先处理原则
设立IT运维关键流程，引入优先处理原则是指要求CIO定义出IT运维的每个关键流程，不仅仅是定义流程是什么，还包括要指出每个关键流程对企业有什么影响和意义。同时，在设置自动化流程时还需要引入优先处理原则，例行的事按常规处理，特别事件要按优先顺序次序处理，也就是把事件细分为例行事件和例外关键事件。
总之，实现IT运维的自动化管理是指通过将IT运维中日常的、大量的重复性工作自动化，把过去的手工执行转为自动化操作。自动化是IT运维工作的升华，自动化运维不单纯是一个维护过程，更是一个管理的提升过程，是IT运维的最高层次，也是未来的发展趋势。
2017 OpenStack峰会：k8S抢尽风头？
精灵云 发表了文章 • 0 个评论 • 1740 次浏览 • 2017-05-11 15:43
编者按：2017年OpenStack峰会（5.8-5.11）正在如火如荼进行， OpenStack和K8s的“相爱相杀”正在陆续上演，K8s可谓抢尽本届峰会的风头，成了不折不扣的主角。虽然大多数美国分析师都认为可以通过大会讨论出未来方向和结果，但笔者认为真正的 ...查看全部
编者按：2017年OpenStack峰会（5.8-5.11）正在如火如荼进行， OpenStack和K8s的“相爱相杀”正在陆续上演，K8s可谓抢尽本届峰会的风头，成了不折不扣的主角。虽然大多数美国分析师都认为可以通过大会讨论出未来方向和结果，但笔者认为真正的结果在企业用户心中。只有实际成功的案例才能真正说明二者微妙的关系，正所谓“黑猫白猫，能抓到老鼠的猫才是好猫”。
2017 OpenStack Summit大会正在如火如荼的进行，在会议开始之前，这三行问题就已引人关注：
**“OpenStack on Kubernetes？
Kubernetes on OpenStack？
How about Kubernetes on OpenStack on Kubernetes？”**
以下是分组会议的话题清单，我们似乎可以从中看出些什么：
Kubernetes和大规模OpenStack；
企业采用Kubernetes和容器；
OpenDaylight Kubernetes和OpenStack Magnum集成；
ESCaaS 4.0，OpenStack和Kubernetes的统一管理平台；
混合云Kubernetes。
没错，一个非常明确的重点：Kubernetes。
2017年，OpenStack在全球范围内的企业数据中心正获得越来越多的部署。OpenStack最初的存在是为了让私有云基础设施能够像公共云一样方便快捷地支持应用程序。回顾OpenStack这些年所遇到的需求和面临的挑战，似乎都通过使用Kubernetes得以解决。
相关组织做了一次问卷调查，调查数字表明，使用OpenStack的受访者中，84%的人很高兴讨论他们在什么行业，他们负责什么方面的工作，但很多人不热衷于回答问卷中最重要的一个问题：“你用什么容器或PaaS平台工具来管理你的应用程序？”
在少数回答了这个问题的人中，大约43％的人表示他们使用Kubernetes来管理他们的应用程序，而其他选项（包括Swarm和Mesos）都低于该数字。
为什么？
峰会这几天，所有人都在围绕这三大问题展开讨论:
1、Kubernetes真的能成为OpenStack的实际应用程序服务管理组件？
如果这个问题换成“OpenStack和Kubernetes在私有云部署中分别扮演什么角色？”那就可以简单地回答说，“OpenStack管理基础设施，Kubernetes管理容器，”
OpenStack的文档指出：Magnum是一个OpenStack项目，它提供容器编排引擎来进行部署和管理。将Magnum与Kubernetes、Swarm或Mesos集成在一起，是一个非常好的思路。
认真的工程师必须提出这个问题：怎样的整合才是最可取的？
2、OpenStack名声大噪，却难以部署和管理吗？
据悉，OpenStack基金会在其4月调查报告中承认，用户的反馈集中在安装方面缺乏一致性，缺乏共同的生命周期管理工具，缺乏自动化部署系统，缺乏标准化升级过程，缺乏对BUG修复的关注，以及几乎所有工作流程中都有难以估量的步骤数量，这些都是OpenStack用户们强烈反馈的问题。
3、谁是OpenStack的领导者和推动者？
几年前，分析师们认为OpenStack重要性是显而易见的，否则惠普就不会投入如此多的资金来推动它。后来，当惠普退出时，一些分析师又宣布OpenStack将走向死亡。
但是很少有人注意到：获得惠普OpenStack业务的SUSE Linux可能更适合惠普向他的客户们提供这些服务。
大多数市场感知中存在着现实，在分析师眼中，该平台的方向即将明确，但对于大多数客户来说，由供应商和小团队供应商提供的案例才最具吸引力。
峰会热切进行中，OpenStack仍然是软件历史上最前所未有的集体努力者之一，相比之下，部分Linux的成功可能才是偶然的。
2017 OpenStack Summit大会正在如火如荼的进行，在会议开始之前，这三行问题就已引人关注：
**“OpenStack on Kubernetes？
Kubernetes on OpenStack？
How about Kubernetes on OpenStack on Kubernetes？”**
以下是分组会议的话题清单，我们似乎可以从中看出些什么：
Kubernetes和大规模OpenStack；
企业采用Kubernetes和容器；
OpenDaylight Kubernetes和OpenStack Magnum集成；
ESCaaS 4.0，OpenStack和Kubernetes的统一管理平台；
混合云Kubernetes。
没错，一个非常明确的重点：Kubernetes。
2017年，OpenStack在全球范围内的企业数据中心正获得越来越多的部署。OpenStack最初的存在是为了让私有云基础设施能够像公共云一样方便快捷地支持应用程序。回顾OpenStack这些年所遇到的需求和面临的挑战，似乎都通过使用Kubernetes得以解决。
相关组织做了一次问卷调查，调查数字表明，使用OpenStack的受访者中，84%的人很高兴讨论他们在什么行业，他们负责什么方面的工作，但很多人不热衷于回答问卷中最重要的一个问题：“你用什么容器或PaaS平台工具来管理你的应用程序？”
在少数回答了这个问题的人中，大约43％的人表示他们使用Kubernetes来管理他们的应用程序，而其他选项（包括Swarm和Mesos）都低于该数字。
为什么？
峰会这几天，所有人都在围绕这三大问题展开讨论:
1、Kubernetes真的能成为OpenStack的实际应用程序服务管理组件？
如果这个问题换成“OpenStack和Kubernetes在私有云部署中分别扮演什么角色？”那就可以简单地回答说，“OpenStack管理基础设施，Kubernetes管理容器，”
OpenStack的文档指出：Magnum是一个OpenStack项目，它提供容器编排引擎来进行部署和管理。将Magnum与Kubernetes、Swarm或Mesos集成在一起，是一个非常好的思路。
认真的工程师必须提出这个问题：怎样的整合才是最可取的？
2、OpenStack名声大噪，却难以部署和管理吗？
据悉，OpenStack基金会在其4月调查报告中承认，用户的反馈集中在安装方面缺乏一致性，缺乏共同的生命周期管理工具，缺乏自动化部署系统，缺乏标准化升级过程，缺乏对BUG修复的关注，以及几乎所有工作流程中都有难以估量的步骤数量，这些都是OpenStack用户们强烈反馈的问题。
3、谁是OpenStack的领导者和推动者？
几年前，分析师们认为OpenStack重要性是显而易见的，否则惠普就不会投入如此多的资金来推动它。后来，当惠普退出时，一些分析师又宣布OpenStack将走向死亡。
但是很少有人注意到：获得惠普OpenStack业务的SUSE Linux可能更适合惠普向他的客户们提供这些服务。
大多数市场感知中存在着现实，在分析师眼中，该平台的方向即将明确，但对于大多数客户来说，由供应商和小团队供应商提供的案例才最具吸引力。
峰会热切进行中，OpenStack仍然是软件历史上最前所未有的集体努力者之一，相比之下，部分Linux的成功可能才是偶然的。
那些影响传统PaaS平台结构的容器编排工具
精灵云 发表了文章 • 2 个评论 • 2203 次浏览 • 2017-05-09 17:25
作者：精灵云
随着PaaS平台结构的演变，可以看到容器编排给企业在平台结构的选择上带来的冲击，可究竟该如何选择，我们需要透过现象看本质。
PaaS平台的演变
传统PaaS平台在云计算技术的发展中经历了几次演变， ...查看全部
作者：精灵云
随着PaaS平台结构的演变，可以看到容器编排给企业在平台结构的选择上带来的冲击，可究竟该如何选择，我们需要透过现象看本质。
PaaS平台的演变
传统PaaS平台在云计算技术的发展中经历了几次演变，我们先来回顾下经典的云平台层次体系的结构。
传统云计算平台的分层结构
如图所示，在经典的PaaS平台结构中，应用运行在PaaS平台所提供的容器环境中，容器在虚拟机基础上完成了第二层次基础设施资源的划分，容器封装了应用正常运行所需的运行环境和系统。然而这类PaaS平台就如同一个“黑盒”，应用完全脱离了租户的控制，进入了完全被托管的状态，这使得开发人员和运维人员对应用和应用运行时的环境掌控力变弱，再加上传统PaaS通常在应用架构选择、支持的环境服务等方面有较强限制，导致此类云平台层次结构运力不足，尤其是在应用出现宕机后尤为凸显。因而在生产环境下又进化出了以IaaS+云平台的分层结构。
典型的IaaS+云平台
IaaS+云平台的层次结构保证了运维人员对底层环境的掌控，但IaaS层不具备贴近应用的资源调度策略，为了弥补了IaaS平台脱离应用的缺陷，出现了很多高效便捷的虚拟机DevOps工具，以虚拟机镜像为基础可以保证生产环境、测试环境、开发环境上的严格一致。目前基于IaaS的云生态环境已经具有相当高的成熟度。
当然，以上这两种经典的云平台分层结构依然还是目前传统云平台搭建意识里的主流，直到Docker的出现。
基于容器的云平台
Docker的出现为云平台带来了一个新的分层结构：基于容器的云平台。相比经典PaaS平台，基于容器的云平台结构更加开放，可直接基于虚拟机或物理机搭建。基于容器镜像的应用发布流程不仅能覆盖整个应用生命周期，还减少了经典PaaS平台对应用架构、支持的软件环境服务等方面的诸多限制，将更多控制力交还给开发和运维人员。
而影响传统平台PaaS结构的核心便是容器编排。
容器编排的演变
容器编排支持打包、部署、隔离、服务发现、扩容和滚动更新，已经在影响驱动成熟企业和初创公司采用容器上起到非常重要作用。
在基于容器的云平台中，运用Docker容器至应用的完整生命周期中时，最困难的便是运行微服务应用程序，即如何创建、管理和自动化临时容器集群。
解决这一挑战的第一个主要工具是Mesos及它的编排工具Marathon，成熟度最高时间最久。下一个得到认同的编排工具是Kubernetes（以下简称K8s），应用最广泛，社区支持度最高。之后Docker Swarm也加入了进来，使用覆盖率也很惊喜。当然，目前国内还出现了自研的容器编排Newben，开发者为Ghostcloud精灵云。
几种容器编排的对比
事实上，如今K8s因为它的可扩展性已经成为了企业主流。它支持广泛的编程语言、基础设施选项，并获得容器生态系统的巨大支持。它将应用层与基础设施层隔离开来，从而能够跨多个云供应商和基础设施设置，实现真正的可移植性。
容器编排K8s和Newben
本文重点介绍在网络、应用迁移、应用快照、模板、负载均衡、弹性伸缩、高可用、CI/CD集成、灰度发布和回滚、镜像集成、日志监控等方面同样优秀的两类容器编排工具Newben和K8s。Newben是Ghostcloud精灵云全自主研发的容器调度引擎，是目前国内唯一自研引擎。（关于Newben的介绍可阅读文章《全自主研发容器调度引擎——Newben》）K8s是目前最主流的容器编排。在此，我们简略地列出了Newben和K8s的部分功能特性，来展示这两种容器调度引擎在网络、应用迁移、负载均衡、弹性伸缩、调度规则等方面的优势。
网络
K8s不支持内置虚拟网络，网络插件选择众多，学习成本更高，但从社区获得的支持也最多。Newben内置支持虚拟网络，支持多子网，支持公有云、主机托管环境、二层和三层网络以及控制网络访问安全。
应用服务和应用栈
在创建应用服务方面， K8s需要多次执行命令工具的操作模式，Newben则采用向导式创建的方式，且支持应用服务分组创建应用栈。
弹性伸缩
Newben和K8s均可以支持CPU的弹性伸缩。
负载均衡
Newben和K8s均可实现负载均衡和高可用集群。
调度规则
K8s的调度规则基于标签选择器，而Newben则同时基于标签选择和指定主机名。
结语
对企业而言，编排工具是容器应用成功的关键，最主流的PaaS解决方案已经拥抱容器，并有新的PaaS 建立在容器编排之上实现管理平台。企业可以选择面向IT运维，部署核心容器编排工具，或面向开发，使用PaaS平台。
推荐阅读：
企业为什么要使用基于Docker的PaaS/CaaS平台
Docker容器云在金融行业的应用
自研容器调度引擎Newben会成为“中国的K8s”？
随着PaaS平台结构的演变，可以看到容器编排给企业在平台结构的选择上带来的冲击，可究竟该如何选择，我们需要透过现象看本质。
PaaS平台的演变
传统PaaS平台在云计算技术的发展中经历了几次演变，我们先来回顾下经典的云平台层次体系的结构。
传统云计算平台的分层结构
如图所示，在经典的PaaS平台结构中，应用运行在PaaS平台所提供的容器环境中，容器在虚拟机基础上完成了第二层次基础设施资源的划分，容器封装了应用正常运行所需的运行环境和系统。然而这类PaaS平台就如同一个“黑盒”，应用完全脱离了租户的控制，进入了完全被托管的状态，这使得开发人员和运维人员对应用和应用运行时的环境掌控力变弱，再加上传统PaaS通常在应用架构选择、支持的环境服务等方面有较强限制，导致此类云平台层次结构运力不足，尤其是在应用出现宕机后尤为凸显。因而在生产环境下又进化出了以IaaS+云平台的分层结构。
典型的IaaS+云平台
IaaS+云平台的层次结构保证了运维人员对底层环境的掌控，但IaaS层不具备贴近应用的资源调度策略，为了弥补了IaaS平台脱离应用的缺陷，出现了很多高效便捷的虚拟机DevOps工具，以虚拟机镜像为基础可以保证生产环境、测试环境、开发环境上的严格一致。目前基于IaaS的云生态环境已经具有相当高的成熟度。
当然，以上这两种经典的云平台分层结构依然还是目前传统云平台搭建意识里的主流，直到Docker的出现。
基于容器的云平台
Docker的出现为云平台带来了一个新的分层结构：基于容器的云平台。相比经典PaaS平台，基于容器的云平台结构更加开放，可直接基于虚拟机或物理机搭建。基于容器镜像的应用发布流程不仅能覆盖整个应用生命周期，还减少了经典PaaS平台对应用架构、支持的软件环境服务等方面的诸多限制，将更多控制力交还给开发和运维人员。
而影响传统平台PaaS结构的核心便是容器编排。
容器编排的演变
容器编排支持打包、部署、隔离、服务发现、扩容和滚动更新，已经在影响驱动成熟企业和初创公司采用容器上起到非常重要作用。
在基于容器的云平台中，运用Docker容器至应用的完整生命周期中时，最困难的便是运行微服务应用程序，即如何创建、管理和自动化临时容器集群。
解决这一挑战的第一个主要工具是Mesos及它的编排工具Marathon，成熟度最高时间最久。下一个得到认同的编排工具是Kubernetes（以下简称K8s），应用最广泛，社区支持度最高。之后Docker Swarm也加入了进来，使用覆盖率也很惊喜。当然，目前国内还出现了自研的容器编排Newben，开发者为Ghostcloud精灵云。
几种容器编排的对比
事实上，如今K8s因为它的可扩展性已经成为了企业主流。它支持广泛的编程语言、基础设施选项，并获得容器生态系统的巨大支持。它将应用层与基础设施层隔离开来，从而能够跨多个云供应商和基础设施设置，实现真正的可移植性。
容器编排K8s和Newben
本文重点介绍在网络、应用迁移、应用快照、模板、负载均衡、弹性伸缩、高可用、CI/CD集成、灰度发布和回滚、镜像集成、日志监控等方面同样优秀的两类容器编排工具Newben和K8s。Newben是Ghostcloud精灵云全自主研发的容器调度引擎，是目前国内唯一自研引擎。（关于Newben的介绍可阅读文章《全自主研发容器调度引擎——Newben》）K8s是目前最主流的容器编排。在此，我们简略地列出了Newben和K8s的部分功能特性，来展示这两种容器调度引擎在网络、应用迁移、负载均衡、弹性伸缩、调度规则等方面的优势。
网络
K8s不支持内置虚拟网络，网络插件选择众多，学习成本更高，但从社区获得的支持也最多。Newben内置支持虚拟网络，支持多子网，支持公有云、主机托管环境、二层和三层网络以及控制网络访问安全。
应用服务和应用栈
在创建应用服务方面， K8s需要多次执行命令工具的操作模式，Newben则采用向导式创建的方式，且支持应用服务分组创建应用栈。
弹性伸缩
Newben和K8s均可以支持CPU的弹性伸缩。
负载均衡
Newben和K8s均可实现负载均衡和高可用集群。
调度规则
K8s的调度规则基于标签选择器，而Newben则同时基于标签选择和指定主机名。
结语
对企业而言，编排工具是容器应用成功的关键，最主流的PaaS解决方案已经拥抱容器，并有新的PaaS 建立在容器编排之上实现管理平台。企业可以选择面向IT运维，部署核心容器编排工具，或面向开发，使用PaaS平台。
推荐阅读：
企业为什么要使用基于Docker的PaaS/CaaS平台
Docker容器云在金融行业的应用
自研容器调度引擎Newben会成为“中国的K8s”？
运维平台信用分——滴滴内部的数据驱动实践
老马 发表了文章 • 0 个评论 • 164 次浏览 • 2019-05-25 21:03
【编者的话】在大家的印象中，运维人员更多的是从属业务的角色。在传统的企业IT中，没有快速的产品迭代，没有每天成百上千次的服务发布和伸缩容，这样的角色看似没有问题。但在如今的 DevOps 时代，日常的运维工作中每天要应对成百上千次的服务发布与线上操作。如果运维 ...查看全部
【编者的话】在大家的印象中，运维人员更多的是从属业务的角色。在传统的企业IT中，没有快速的产品迭代，没有每天成百上千次的服务发布和伸缩容，这样的角色看似没有问题。但在如今的 DevOps 时代，日常的运维工作中每天要应对成百上千次的服务发布与线上操作。如果运维人员（即SRE）仍然只是被动的去应对这种变化，所造成的结果，必然是疲于应付，最终会对全平台的业务稳定性造成很大隐患。
那么，在这种量变引起质变的挑战中，运维人员应该发挥怎样的作用，才能适应新业务的挑战呢？笔者之前曾就职于IBM Cloud部门，现在就职于滴滴运维部，长期从事自动化运维方面的工作，下面就结合自己之前的经验和目前的工作，谈谈自己的一些见解。如果你想和更多运维技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
#来自业务的挑战
无论是在滴滴还是在之前的部门，在业务发展的初期阶段，都不可避免的经历了粗犷型的扩张阶段，比如业务量指数级上升，用户量急剧增加，每时每刻都有服务模块的迭代。
在业务优先的前提下，运维人员承担着巨大的运维压力。以监控为例，用户添加监控不规范，会造成报警频发，报警有效性不足，导致的后果就是容易让真正有价值的报警湮没在海量数据中，同时，也会造成对报警资源的浪费，比如，研发同学不区分测试、线上环境，随意的添加报警采集指标，会对监控系统的存储，查询带来极大的挑战。再比如部署系统，不按照规范，在高峰期更新服务，一旦出问题，会造成整个应用的服务不可用。这样的例子有很多。
#如何应对
如果上述的问题一直延续下去，运维工作必然带来巨大的挑战，并且会严重影响线上服务的稳定性。面对这些问题，滴滴运维团队的同学也在一起思考，运维应该不仅仅去被动的适应业务，而是要从平台稳定性出发，去指导研发同学，如何规范的执行变更，如何合理的使用监控资源以及其它公司IT基础设施。
我们想到的解决方法就是“数据说话”，尽可能的去量化监控、部署及基础组件（MySQL、Codis、ZooKeeper）的使用。然后用数字去指导研发的同学，尽可能的去匹配我们给出的“最佳实践”，从而减少造成线上业务不稳定的隐患。
所以，滴滴运维部推出了“风险量化平台”，包含“变更信用分”（用来度量服务的变更操作，比如服务部署上线，配置变更等）、“监控健康分”（用来度量用户对报警监控的使用），从而打造一个“看得见的手”，驱动业务同学来一起提高线上稳定性。
##数据驱动的难点有三个方面
首先是如何获取数据？这是“风险量化平台”的基础。使用监控系统，部署一个服务，执行一次配置变更，都是一个个用户操作，很难用数字去表达。为此我们结合运维经验，基于对操作每个步骤的详尽输出，近可能的去用数字维度来衡量用户操作。比如以部署为例，会以灰度发布中间的暂停时间是否满足一定时长，是否有在上线高峰期操作记录，部署过程中是否执行了double-check，在哪个阶段执行了回滚等等，来形成一个个的打分项。
其次是如何去制定风险量化的标准，也就是如何用各个指标去构造一个最佳实践。这更像是一个数学建模，里面涉及到大量的运维经验积累，以我们新推出的监控健康分为例，我们遵循着“有服务必有监控，有报警必须处理”的原则，对于每个服务，要求衡量的标准包括，是否有存活指标监控（进程、端口等）；是否有基础指标监控（如cpu.idle，mem.used，disk.used）；是否添加了上下游监控，报警是否有效，即报警接收人是否过多（因为大家都收到报警，最终的结果，往往意味着大家都不会处理报警），报警是否被及时处理（运维领域也有MTTA， MTTR，即报警平均响应时间，和报警及时处理时间这样的概念）；是否配置了监控大盘，方便我们日常巡检。
各个量化项目占据不同的权重（如下方的监控健康分剖析图）， 比如我们根据滴滴目前的服务特点，存活指标占比40%， 报警有效性占比30%，推动业务去收敛报警，和完善监控。监控健康分以80分为及格线，寻找出监控漏洞，并指导用户加以改进。 用这样的方法，可以让研发同学尽可能的减少漏配监控的事情发生，提高线上服务的稳定性。
最后的难点是如何驱动？这是我们现在着力想的一个点。风险量化实际上就是总结前人踩过的坑，趟过的雷，去告诉后面的同学，提前来规避风险，这是运维部门对公司业务稳定性的一大贡献。
现在已有的做法是如下图（各部门变更信用分排名图）所示，通过计算、打分、全公司各个业务线排名，将风险量化数据和反应出的问题推送给各个业务线的leader。以竞赛方式去推动各个业务线重视风险量化。我们还计划以监控健康分去驱动报警有效性的建设，完善报警值班制度，避免群发报警又无人处理，报警配置不合理这种现象的发生。
#效果如何
目前的风险量化体系包含“变更信用分”，“监控健康分”，其中变更信用分已经上线一年多了，在2018年，从下图能明显看到信用分在稳步上升。
带来结果是什么呢？ 下面是本年度故障case统计图，能明显的看到这种趋势，故障case数量随着变更信用分的提高在稳步下降。考虑到同时期的变更数量也在一直增加，这种下降趋势就更加明显了。
我们期望其它的信用分机制，也能给业务稳定性带来这样积极的结果。
#未来展望
对于未来的展望，首先希望能对尽可能多的涉及线上操作的内容进行风险量化，比如业务使用的中间件／基础组件，业务中涉及安全的服务是否遵循了相应的规范，是否有密码／数据泄漏风险。
其次，我们仍然需要对已有的运维经验进行总结，结合经验，利用量化分数去构建“最佳实践”，指导大家去遵守。
最后是如何去驱动，将总结的数据价值，最大化的发挥出来。
原文链接：https://mp.weixin.qq.com/s/AYjpv2GSYDLl0pB9tHqkrg
那么，在这种量变引起质变的挑战中，运维人员应该发挥怎样的作用，才能适应新业务的挑战呢？笔者之前曾就职于IBM Cloud部门，现在就职于滴滴运维部，长期从事自动化运维方面的工作，下面就结合自己之前的经验和目前的工作，谈谈自己的一些见解。如果你想和更多运维技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
#来自业务的挑战
无论是在滴滴还是在之前的部门，在业务发展的初期阶段，都不可避免的经历了粗犷型的扩张阶段，比如业务量指数级上升，用户量急剧增加，每时每刻都有服务模块的迭代。
在业务优先的前提下，运维人员承担着巨大的运维压力。以监控为例，用户添加监控不规范，会造成报警频发，报警有效性不足，导致的后果就是容易让真正有价值的报警湮没在海量数据中，同时，也会造成对报警资源的浪费，比如，研发同学不区分测试、线上环境，随意的添加报警采集指标，会对监控系统的存储，查询带来极大的挑战。再比如部署系统，不按照规范，在高峰期更新服务，一旦出问题，会造成整个应用的服务不可用。这样的例子有很多。
#如何应对
如果上述的问题一直延续下去，运维工作必然带来巨大的挑战，并且会严重影响线上服务的稳定性。面对这些问题，滴滴运维团队的同学也在一起思考，运维应该不仅仅去被动的适应业务，而是要从平台稳定性出发，去指导研发同学，如何规范的执行变更，如何合理的使用监控资源以及其它公司IT基础设施。
我们想到的解决方法就是“数据说话”，尽可能的去量化监控、部署及基础组件（MySQL、Codis、ZooKeeper）的使用。然后用数字去指导研发的同学，尽可能的去匹配我们给出的“最佳实践”，从而减少造成线上业务不稳定的隐患。
所以，滴滴运维部推出了“风险量化平台”，包含“变更信用分”（用来度量服务的变更操作，比如服务部署上线，配置变更等）、“监控健康分”（用来度量用户对报警监控的使用），从而打造一个“看得见的手”，驱动业务同学来一起提高线上稳定性。
##数据驱动的难点有三个方面
首先是如何获取数据？这是“风险量化平台”的基础。使用监控系统，部署一个服务，执行一次配置变更，都是一个个用户操作，很难用数字去表达。为此我们结合运维经验，基于对操作每个步骤的详尽输出，近可能的去用数字维度来衡量用户操作。比如以部署为例，会以灰度发布中间的暂停时间是否满足一定时长，是否有在上线高峰期操作记录，部署过程中是否执行了double-check，在哪个阶段执行了回滚等等，来形成一个个的打分项。
其次是如何去制定风险量化的标准，也就是如何用各个指标去构造一个最佳实践。这更像是一个数学建模，里面涉及到大量的运维经验积累，以我们新推出的监控健康分为例，我们遵循着“有服务必有监控，有报警必须处理”的原则，对于每个服务，要求衡量的标准包括，是否有存活指标监控（进程、端口等）；是否有基础指标监控（如cpu.idle，mem.used，disk.used）；是否添加了上下游监控，报警是否有效，即报警接收人是否过多（因为大家都收到报警，最终的结果，往往意味着大家都不会处理报警），报警是否被及时处理（运维领域也有MTTA， MTTR，即报警平均响应时间，和报警及时处理时间这样的概念）；是否配置了监控大盘，方便我们日常巡检。
各个量化项目占据不同的权重（如下方的监控健康分剖析图）， 比如我们根据滴滴目前的服务特点，存活指标占比40%， 报警有效性占比30%，推动业务去收敛报警，和完善监控。监控健康分以80分为及格线，寻找出监控漏洞，并指导用户加以改进。 用这样的方法，可以让研发同学尽可能的减少漏配监控的事情发生，提高线上服务的稳定性。
最后的难点是如何驱动？这是我们现在着力想的一个点。风险量化实际上就是总结前人踩过的坑，趟过的雷，去告诉后面的同学，提前来规避风险，这是运维部门对公司业务稳定性的一大贡献。
现在已有的做法是如下图（各部门变更信用分排名图）所示，通过计算、打分、全公司各个业务线排名，将风险量化数据和反应出的问题推送给各个业务线的leader。以竞赛方式去推动各个业务线重视风险量化。我们还计划以监控健康分去驱动报警有效性的建设，完善报警值班制度，避免群发报警又无人处理，报警配置不合理这种现象的发生。
#效果如何
目前的风险量化体系包含“变更信用分”，“监控健康分”，其中变更信用分已经上线一年多了，在2018年，从下图能明显看到信用分在稳步上升。
带来结果是什么呢？ 下面是本年度故障case统计图，能明显的看到这种趋势，故障case数量随着变更信用分的提高在稳步下降。考虑到同时期的变更数量也在一直增加，这种下降趋势就更加明显了。
我们期望其它的信用分机制，也能给业务稳定性带来这样积极的结果。
#未来展望
对于未来的展望，首先希望能对尽可能多的涉及线上操作的内容进行风险量化，比如业务使用的中间件／基础组件，业务中涉及安全的服务是否遵循了相应的规范，是否有密码／数据泄漏风险。
其次，我们仍然需要对已有的运维经验进行总结，结合经验，利用量化分数去构建“最佳实践”，指导大家去遵守。
最后是如何去驱动，将总结的数据价值，最大化的发挥出来。
原文链接：https://mp.weixin.qq.com/s/AYjpv2GSYDLl0pB9tHqkrg
运维工程师不得不看的经验教训和注意事项
大卫 发表了文章 • 0 个评论 • 222 次浏览 • 2019-05-22 19:48
#一、线上操作规范
##测试使用
当初学习Linux的使用，从基础到服务到集群，都是在虚拟机做的，虽然老师告诉我们跟真机没有什么差别，可是对真实环境的渴望日渐上升，不过虚拟机的各种快照却让我们养成了各种手贱的习惯，以致于拿到服务器操作权 ...查看全部
#一、线上操作规范
##测试使用
当初学习Linux的使用，从基础到服务到集群，都是在虚拟机做的，虽然老师告诉我们跟真机没有什么差别，可是对真实环境的渴望日渐上升，不过虚拟机的各种快照却让我们养成了各种手贱的习惯，以致于拿到服务器操作权限时候，就迫不及待的想去试试，记得上班第一天，老大把root密码交给我，由于只能使用putty，我就想使用xshell，于是悄悄登录服务器尝试改为xshell+密钥登录，因为没有测试，也没有留一个ssh连接，所有重启sshd服务器之后，自己就被挡在服务器之外了，幸好当时我备份了sshd_config文件，后来让机房人员cp过去就可以了，幸亏这是一家小公司，不然直接就被干了……庆幸当年运气比较好。如果你想和更多运维技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
第二个例子是关于文件同步的，大家都知道rsync同步很快，可是他删除文件的速度大大超过了rm -rf，在rsync中有一个命令是，以某目录为准同步某文件（如果第一个目录是空的，那么结果可想而知），源目录（有数据的）就会被删除，当初我就是因为误操作，以及缺乏测试，就目录写反了，关键是没有备份……生产环境数据被删了
没备份，大家自己想后果吧，其重要性不言而喻。
##Enter前再三确认
关于rm -rf / var这种错误，我相信手快的人，或者网速比较慢的时候，出现的几率相当大
当你发现执行完之后，你的心至少是凉了半截。
大家可能会说，我按了这么多次都没出过错，不用怕，我只想说当出现一次你就明白了，不要以为那些运维事故都是在别人身上，如果你不注意，下一个就是你。
##切忌多人操作
我在的上一家公司，运维管理相当混乱，举一个最典型的例子吧，离职好几任的运维都有服务器root密码。
通常我们运维接到任务，都会进行简单查看如果无法解决，就请求他人帮忙，可是当问题焦头烂额的时候，客服主管（懂点Linux），网管，你上司一起调试一个服务器，当你各种百度,各种对照，完了发现，你的服务器配置文件，跟上次你修改不一样了，然后再改回来，然后再谷歌，兴冲冲发现问题，解决了，别人却告诉你，他也解决了，修改的是不同的参数……这个，我就真不知道哪个是问题真正的原因了，当然这还是好的，问题解决了，皆大欢喜，可是你遇到过你刚修改的文件，测试无效，再去修改发现文件又被修改的时候呢？真的很恼火，切忌多人操作。
##先备份后操作
养成一个习惯，要修改数据时，先备份，比如.conf的配置文件。另外，修改配置文件时，建议注释原选项，然后再复制，修改，再者说，如果第一个例子中，有数据库备份，那rsync的误操作不久没事了吧。所以说丢数据库非一朝一夕，随便备份一个就不用那么惨。
#二、涉及数据
##慎用rm -rf
网上的例子很多，各种rm -rf /，各种删除主数据库，各种运维事故……
一点小失误就会造成很大的损失。如果真需要删除，一定要谨慎。
##备份大于一切
本来上面都有各种关于备份，但是我想把它划分在数据类再次强调，备份非常之重要哇。我记得我的老师说过一句话，涉及到数据何种的谨慎都不为过。我就职的公司有做第三方支付网站和网贷平台的，第三方支付是每两个小时完全备份一次，网贷平台是每20分钟备份一次，我不多说了，大家自己斟酌吧。
##稳定大于一切
其实不止是数据，在整个服务器环境，都是稳定大于一切，不求最快，但求最稳定，求可用性。所以未经测试，不要再服务器使用新的软件，比如Nginx+php-fpm，生产环境中PHP各种挂啊。重启下就好了，或者换apache就好了。
##保密大于一切
现在各种艳照门漫天飞，各种路由器后门，所以说，涉及到数据，不保密是不行的。
##三、涉及安全
##SSH
* 更改默认端口（当然如果专业要黑你，扫描下就出来了）
* 禁止root登录
* 使用普通用户+key认证+sudo规则+IP地址+用户限制
* 使用hostdeny类似的防爆里破解软件（超过几次尝试直接拉黑）
* 筛选/etc/passwd中login的用户
##防火墙
防火墙生产环境一定要开，并且要遵循最小原则，drop所有，然后放行需要的服务端口。
##精细权限和控制粒度
能使用普通用户启动的服务坚决不使用root，把各种服务权限控制到最低，控制粒度要精细。
##入侵检测和日志监控
* 使用第三方软件，时刻检测系统关键文件以及各种服务配置文件的改动，比如：/etc/passwd，/etc/my.cnf，/etc/httpd/con/httpd.con等；
* 使用集中化的日志监控体系，监控/var/log/secure，/etc/log/message，ftp上传下载文件等报警错误日志；
* 另外针对端口扫描，也可以使用一些第三方软件，发现被扫描就直接拉入host.deny。这些信息对于系统被入侵后排错很有帮助。有人说过，一个公司在安全投入的成本跟他被安全攻击损失的成本成正比，安全是一个很大的话题。
也是一个很基础的工作，把基础做好了，就能相当的提高系统安全性，其他的就是安全高手做的了
#四、日常监控
##系统运行监控
好多人踏入运维都是从监控做起，大的公司一般都有专业24小时监控运维。系统运行监控一般包括硬件占用率，常见的有：内存，硬盘，CPU，网卡，os包括登录监控，系统关键文件监控。
定期的监控可以预测出硬件损坏的概率，并且给调优带来很实用的功能
##服务运行监控
服务监控一般就是各种应用，Web，DB，LVS等，这一般都是监控一些指标。
在系统出现性能瓶颈的时候就能很快发现并解决。
##日志监控
这里的日志监控跟安全的日志监控类似，但这里一般都是硬件，os，应用程序的报错和警报信息。
监控在系统稳定运行的时候确实没啥用，但是一旦出现问题，你又没做监控，就会很被动了。
#五、性能调优
##深入了解运行机制
其实按一年多的运维经验来说，谈调优根本就是纸上谈兵，但是我只是想简单总结下，如果有更深入的了解，我会更新。在对软件进行优化之前，比如要深入了解一个软件的运行机制，比如Nginx和Apache，大家都说Nginx快，那就必须知道Nginx为什么快，利用什么原理，处理请求比Apache，并且要能跟别人用浅显易懂的话说出来，必要的时候还要能看懂源代码，否则一切以参数为调优对象的文档都是瞎谈。
##调优框架以及先后
熟悉了底层运行机制，就要有调优的框架和先后顺序，比如数据库出现瓶颈，好多人直接就去更改数据库的配置文件，我的建议是，先根据瓶颈去分析，查看日志，写出来调优方向，然后再入手，并且数据库服务器调优应该是最后一步，最先的应该是硬件和操作系统，现在的数据库服务器都是在各种测试之后才会发布的。
适用于所有操作系统，不应该先从他入手。
##每次只调一个参数
每次只调一个参数，这个相比大家都了解，调的多了，你就自己就迷糊了。
##基准测试
判断调优是否有用，和测试一个新版本软件的稳定性和性能等方面，就必须要基准测试了，测试要涉及很多因素。
测试是否接近业务真实需求这要看测试人的经验了，相关资料大家可以参考《高性能MySQL》第三版相当的好。
我的老师曾说过，没有放之四海皆准的参数，任何参数更改任何调优都必须符合业务场景，所以不要再谷歌什么什么调优了，对你的提升和业务环境的改善没有长久作用
#六、运维心态
##控制心态
很多rm -rf /data都在下班的前几分钟，都在烦躁的高峰，那么你还不打算控制下你的心态么？
有人说了，烦躁也要上班，可是你可以在烦躁的时候尽量避免处理关键数据环境。
越是有压力，越要冷静，不然会损失更多。
大多人都有rm -rf /data/mysql的经历，发现删除之后，那种心情你可以想象一下，可是如果没有备份，你急又有什么用，一般这种情况下，你就要冷静想下最坏打算了，对于MySQL来说，删除了物理文件，一部分表还会存在内存中，所以断开业务，但是不要关闭mysql数据库，这对恢复很有帮助，并使用dd复制硬盘，然后你再进行恢复。
当然了大多时候你就只能找数据恢复公司了。
试想一下，数据被删了，你各种操作，关闭数据库，然后修复，不但有可能覆盖文件，还找不到内存中的表了。
##对数据负责
生产环境不是儿戏，数据库也不是儿戏，一定要对数据负责。不备份的后果是非常严重的。
##追根究底
很多运维人员比较忙，遇到问题解决就不会再管了，记得去年一个客户的网站老是打不开，经过PHP代码报错。
发现是session和whos_online损坏，前任运维是通过repair修复的，我就也这样修复了，但是过了几个小时，又出现了。
反复三四次之后，我就去谷歌数据库表莫名损坏原因：一是MyISAM的bug，二是mysqlbug，三是MySQL在写入过程中
被kill，最后发现是内存不够用，导致OOM kill了mysqld进程。
并且没有swap分区，后台监控内存是够用的，最后升级物理内存解决。
##测试和生产环境
在重要操作之前一定要看自己所在的机器，尽量避免多开窗口。
原文链接：http://www.cnblogs.com/yihr/p/9593795.html
##测试使用
当初学习Linux的使用，从基础到服务到集群，都是在虚拟机做的，虽然老师告诉我们跟真机没有什么差别，可是对真实环境的渴望日渐上升，不过虚拟机的各种快照却让我们养成了各种手贱的习惯，以致于拿到服务器操作权限时候，就迫不及待的想去试试，记得上班第一天，老大把root密码交给我，由于只能使用putty，我就想使用xshell，于是悄悄登录服务器尝试改为xshell+密钥登录，因为没有测试，也没有留一个ssh连接，所有重启sshd服务器之后，自己就被挡在服务器之外了，幸好当时我备份了sshd_config文件，后来让机房人员cp过去就可以了，幸亏这是一家小公司，不然直接就被干了……庆幸当年运气比较好。如果你想和更多运维技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
第二个例子是关于文件同步的，大家都知道rsync同步很快，可是他删除文件的速度大大超过了rm -rf，在rsync中有一个命令是，以某目录为准同步某文件（如果第一个目录是空的，那么结果可想而知），源目录（有数据的）就会被删除，当初我就是因为误操作，以及缺乏测试，就目录写反了，关键是没有备份……生产环境数据被删了
没备份，大家自己想后果吧，其重要性不言而喻。
##Enter前再三确认
关于rm -rf / var这种错误，我相信手快的人，或者网速比较慢的时候，出现的几率相当大
当你发现执行完之后，你的心至少是凉了半截。
大家可能会说，我按了这么多次都没出过错，不用怕，我只想说当出现一次你就明白了，不要以为那些运维事故都是在别人身上，如果你不注意，下一个就是你。
##切忌多人操作
我在的上一家公司，运维管理相当混乱，举一个最典型的例子吧，离职好几任的运维都有服务器root密码。
通常我们运维接到任务，都会进行简单查看如果无法解决，就请求他人帮忙，可是当问题焦头烂额的时候，客服主管（懂点Linux），网管，你上司一起调试一个服务器，当你各种百度,各种对照，完了发现，你的服务器配置文件，跟上次你修改不一样了，然后再改回来，然后再谷歌，兴冲冲发现问题，解决了，别人却告诉你，他也解决了，修改的是不同的参数……这个，我就真不知道哪个是问题真正的原因了，当然这还是好的，问题解决了，皆大欢喜，可是你遇到过你刚修改的文件，测试无效，再去修改发现文件又被修改的时候呢？真的很恼火，切忌多人操作。
##先备份后操作
养成一个习惯，要修改数据时，先备份，比如.conf的配置文件。另外，修改配置文件时，建议注释原选项，然后再复制，修改，再者说，如果第一个例子中，有数据库备份，那rsync的误操作不久没事了吧。所以说丢数据库非一朝一夕，随便备份一个就不用那么惨。
#二、涉及数据
##慎用rm -rf
网上的例子很多，各种rm -rf /，各种删除主数据库，各种运维事故……
一点小失误就会造成很大的损失。如果真需要删除，一定要谨慎。
##备份大于一切
本来上面都有各种关于备份，但是我想把它划分在数据类再次强调，备份非常之重要哇。我记得我的老师说过一句话，涉及到数据何种的谨慎都不为过。我就职的公司有做第三方支付网站和网贷平台的，第三方支付是每两个小时完全备份一次，网贷平台是每20分钟备份一次，我不多说了，大家自己斟酌吧。
##稳定大于一切
其实不止是数据，在整个服务器环境，都是稳定大于一切，不求最快，但求最稳定，求可用性。所以未经测试，不要再服务器使用新的软件，比如Nginx+php-fpm，生产环境中PHP各种挂啊。重启下就好了，或者换apache就好了。
##保密大于一切
现在各种艳照门漫天飞，各种路由器后门，所以说，涉及到数据，不保密是不行的。
##三、涉及安全
##SSH
* 更改默认端口（当然如果专业要黑你，扫描下就出来了）
* 禁止root登录
* 使用普通用户+key认证+sudo规则+IP地址+用户限制
* 使用hostdeny类似的防爆里破解软件（超过几次尝试直接拉黑）
* 筛选/etc/passwd中login的用户
##防火墙
防火墙生产环境一定要开，并且要遵循最小原则，drop所有，然后放行需要的服务端口。
##精细权限和控制粒度
能使用普通用户启动的服务坚决不使用root，把各种服务权限控制到最低，控制粒度要精细。
##入侵检测和日志监控
* 使用第三方软件，时刻检测系统关键文件以及各种服务配置文件的改动，比如：/etc/passwd，/etc/my.cnf，/etc/httpd/con/httpd.con等；
* 使用集中化的日志监控体系，监控/var/log/secure，/etc/log/message，ftp上传下载文件等报警错误日志；
* 另外针对端口扫描，也可以使用一些第三方软件，发现被扫描就直接拉入host.deny。这些信息对于系统被入侵后排错很有帮助。有人说过，一个公司在安全投入的成本跟他被安全攻击损失的成本成正比，安全是一个很大的话题。
也是一个很基础的工作，把基础做好了，就能相当的提高系统安全性，其他的就是安全高手做的了
#四、日常监控
##系统运行监控
好多人踏入运维都是从监控做起，大的公司一般都有专业24小时监控运维。系统运行监控一般包括硬件占用率，常见的有：内存，硬盘，CPU，网卡，os包括登录监控，系统关键文件监控。
定期的监控可以预测出硬件损坏的概率，并且给调优带来很实用的功能
##服务运行监控
服务监控一般就是各种应用，Web，DB，LVS等，这一般都是监控一些指标。
在系统出现性能瓶颈的时候就能很快发现并解决。
##日志监控
这里的日志监控跟安全的日志监控类似，但这里一般都是硬件，os，应用程序的报错和警报信息。
监控在系统稳定运行的时候确实没啥用，但是一旦出现问题，你又没做监控，就会很被动了。
#五、性能调优
##深入了解运行机制
其实按一年多的运维经验来说，谈调优根本就是纸上谈兵，但是我只是想简单总结下，如果有更深入的了解，我会更新。在对软件进行优化之前，比如要深入了解一个软件的运行机制，比如Nginx和Apache，大家都说Nginx快，那就必须知道Nginx为什么快，利用什么原理，处理请求比Apache，并且要能跟别人用浅显易懂的话说出来，必要的时候还要能看懂源代码，否则一切以参数为调优对象的文档都是瞎谈。
##调优框架以及先后
熟悉了底层运行机制，就要有调优的框架和先后顺序，比如数据库出现瓶颈，好多人直接就去更改数据库的配置文件，我的建议是，先根据瓶颈去分析，查看日志，写出来调优方向，然后再入手，并且数据库服务器调优应该是最后一步，最先的应该是硬件和操作系统，现在的数据库服务器都是在各种测试之后才会发布的。
适用于所有操作系统，不应该先从他入手。
##每次只调一个参数
每次只调一个参数，这个相比大家都了解，调的多了，你就自己就迷糊了。
##基准测试
判断调优是否有用，和测试一个新版本软件的稳定性和性能等方面，就必须要基准测试了，测试要涉及很多因素。
测试是否接近业务真实需求这要看测试人的经验了，相关资料大家可以参考《高性能MySQL》第三版相当的好。
我的老师曾说过，没有放之四海皆准的参数，任何参数更改任何调优都必须符合业务场景，所以不要再谷歌什么什么调优了，对你的提升和业务环境的改善没有长久作用
#六、运维心态
##控制心态
很多rm -rf /data都在下班的前几分钟，都在烦躁的高峰，那么你还不打算控制下你的心态么？
有人说了，烦躁也要上班，可是你可以在烦躁的时候尽量避免处理关键数据环境。
越是有压力，越要冷静，不然会损失更多。
大多人都有rm -rf /data/mysql的经历，发现删除之后，那种心情你可以想象一下，可是如果没有备份，你急又有什么用，一般这种情况下，你就要冷静想下最坏打算了，对于MySQL来说，删除了物理文件，一部分表还会存在内存中，所以断开业务，但是不要关闭mysql数据库，这对恢复很有帮助，并使用dd复制硬盘，然后你再进行恢复。
当然了大多时候你就只能找数据恢复公司了。
试想一下，数据被删了，你各种操作，关闭数据库，然后修复，不但有可能覆盖文件，还找不到内存中的表了。
##对数据负责
生产环境不是儿戏，数据库也不是儿戏，一定要对数据负责。不备份的后果是非常严重的。
##追根究底
很多运维人员比较忙，遇到问题解决就不会再管了，记得去年一个客户的网站老是打不开，经过PHP代码报错。
发现是session和whos_online损坏，前任运维是通过repair修复的，我就也这样修复了，但是过了几个小时，又出现了。
反复三四次之后，我就去谷歌数据库表莫名损坏原因：一是MyISAM的bug，二是mysqlbug，三是MySQL在写入过程中
被kill，最后发现是内存不够用，导致OOM kill了mysqld进程。
并且没有swap分区，后台监控内存是够用的，最后升级物理内存解决。
##测试和生产环境
在重要操作之前一定要看自己所在的机器，尽量避免多开窗口。
原文链接：http://www.cnblogs.com/yihr/p/9593795.html
2019运维技能风向标
尼古拉斯 发表了文章 • 0 个评论 • 257 次浏览 • 2019-05-20 09:04
运维是一个融合多学科（网络、系统、开发、安全、应用架构、存储等）的综合性技术岗位，从最初的网络管理（网管）发展到现在的系统运维工程师、网络运维工程师、安全运维工程师、运维开发工程师等，可以看出，运维的分工一直在细化，并且对综合技能要求越来越高，可以看出，未来运 ...查看全部
运维是一个融合多学科（网络、系统、开发、安全、应用架构、存储等）的综合性技术岗位，从最初的网络管理（网管）发展到现在的系统运维工程师、网络运维工程师、安全运维工程师、运维开发工程师等，可以看出，运维的分工一直在细化，并且对综合技能要求越来越高，可以看出，未来运维的发展趋势是高、精、尖，高表示高度，精表示精通，尖表示尖端，也就是运维职场一定要站在一定的技术高度，在多个技术领域中，要精通某项技能，同时对尖端前沿技术一定要能掌控趋势。如果你想和更多运维技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
#运维职位的发展和趋势
根据不同的运维领域和技术面以及分工流程三个方面来了解下2019年运维职位的发展趋势。
##按领域来划分
##按技术切面来分
##按流程来划分
#系统运维技能图谱
系统运维是运维的基础，新的一年中，对基础运维技能要求也在提高，打好系统运维基础，才能深入学习后面的各种运维技能。
下图列出了系统运维要掌握的必备技能：
#Web运维技能图谱
Web运维是运维岗位中岗位最多的一个，薪资也相对较高，但需要掌握的知识点也比较多，新的技能要掌握，老的运维技能也不能丢，下图列出了Web运维要掌握的各种必备技能。
#大数据运维技能图谱
大数据从2017年开始逐渐走到生活的各个角落，2018年在逐渐落地，而在2019年，大数据依然火热，加上国家对大数据产业的扶持，大数据产业在新的一年岗位需求一定会更加大，因此掌握大数据运维技能，就走在了运维的前沿，下图列出了大数据运维要掌握的各种必备技能。
#容器运维技能图谱
容器的产生，是一次IT行业的革命，2015 年到 2016 年，是业界普遍认为的容器技术爆发的一年，短短一年多时间里，容器技术在中国大陆完成了从零星概念到烽火燎原的壮举。
时至今日，容器技术在国内大多数企业中落地已成为一种共识，而国内的生态系统，也呈现出了企业产品、开源社区和公有云齐头并进的良好局面。因此，2019年也是容器继续快速落地的一年，下图列出了大数据运维要掌握的各种必备技能。
#数据为王的时代
万丈高楼平地起，高楼稳不稳取决于地基是否扎实。运维数据便是运维管理这座高楼的地基。运维数据大致分为CMDB、日志、生产DB、知识库四个方面。
* CMDB中文是配置管理数据库，存储与管理企业IT架构中设备的各种配置信息，主要是IT资产管理信息。
* 日志数据保护了企业服务器上运行的各种系统产生的应用日志，系统日志、设备日志、数据库日志等数据，这部分数据是企业数据的核心。
* DB数据主要是所有IT系统的数据库信息，包括运维管理系统本身的数据库，数据库包含生产数据库、测试数据库、开发数据库三种类型。
* 知识库主要存储日常开发、测试、运维管理中发生的事件、问题以及一些经典问题的解决和常用的解决方案，主要起到运维管理辅助的功能。
对数据的维护和管理只管重要，特别是日志数据，对运维来说，通过日志可以比较准确全面地知道系统或是设备的运行情况，可以返查问题产生的原因，还原问题发生的整个过程。通过日志也可以提前预测系统可能要发生的问题或是故障，如系统安全日志，如果网络攻 击会在系统安全日志中有一定的体现。
下面简单介绍下，运维重点收集的日志数据有哪些部分以及用途。
##系统日志
系统日志主要指的是操作系统的日志，主要在/var/log下的各种日志信息。包含系统操作日志、系统安全日志、定时任务日志等。系统日志是运维管理安全模块中审计的重要依据。一般默认的操作系统日志不能满足要求，需要对系统的参数进行修改，如为history命令加上时间戳、IP，并且长久保留历史等功能。并且对日志文件进行处理，不允许用户进行清空命令，只能追加。
##应用日志
应用日志主要记录应用服务的健康运行情况以及业务操作的具体日志两部分。应用监控运行情况反应应用服务的健康状态，如果应用占用CPU或是内存过高或是忽高忽低不定，都可以通过分析应用日志结合业务操作日志得出结论。业务操作日志可以为业务审计提供主要依据。有一些系统喜欢把业务操作日志写到数据库中，这个也是需要注意的。不过不管在哪个地方，要求是不可缺少的，它为以后业务审计和问题返查提供依据。
##数据库日志
数据库日志主要反馈数据库的运行情况。通过监控和管理数据库的日志，及时了解数据库的运行情况，遇到问题及时解决等。可以通过数据库日志结合数据库系统自带的数据库如Oracle的系统视图v$开头，MySQL的performance_schema等。虽然数据库的一些信息不是存在日志中而是在数据库里面，但是也可以作为数据库日志的一部分进行管理和监控，已便我们及时知道数据库的监控状况，从而预防可能出现的问题。
##设备日志
设备日志一般是一个比较容易忽略的地方，但设备日志往往可以反映设备的运行情况。交换机故障，防火墙故障等设备故障都可能引起大面积的系统和服务故障。所以设备日志一定要收集，分析和监控预警。常用的设备日志有交换机日志、防火墙日志、网络安全设备日志等。
这么多的日志，运维要通过各种手段完成日志的收集、过滤分析、可视化展示，那么如何实现这些功能呢，方法很多，例如ELK集成套件（Elasticsearch，Logstash，Kibana）就可以轻松实现日志数据的实时收集、分析传输以及图形化展示。
* Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
* Logstash主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，Server端负责将收到的各节点日志进行过滤、修改等操作在一并发往Elasticsearch上去。
* Kibana也是一个开源和免费的工具，Kibana可以为Logstash和ElasticSearch提供的日志分析友好的Web界面，可以帮助汇总、分析和搜索重要数据日志。
另外，还有Filebeat可以替换Logstash作为日志收集工具，Filebeat隶属于Beats。目前Beats包含四种工具：
* Packetbeat（搜集网络流量数据）
* Topbeat（搜集系统、进程和文件系统级别的CPU和内存使用情况等数据）
* Filebeat（搜集文件数据）
* Winlogbeat（搜集Windows事件日志数据）
可以看到，Beats涵盖了所有收集日志数据的各个方面。
那么要如何使用ELK呢，根据日志量的不同，对应的ELK架构也不尽相同，看下面几个常见架构：
此架构主要是将Logstash部署在各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch再将数据以分片的形式压缩存储，并提供多种API供用户查询、操作。用户可以通过Kibana Web直观的对日志进行查询，并根据需求生成数据报表。
此架构的优点是搭建简单，易于上手。缺点是Logstash消耗系统资源比较大，运行时占用CPU和内存资源较高。另外，由于没有消息队列缓存，可能存在数据丢失的风险。此架构建议供初学者或数据量小的环境使用。
由此衍生出来了第二种架构：
此架构主要特点是引入了消息队列机制，位于各个节点上的Logstash Agent（一级Logstash，主要用来传输数据）先将数据传递给消息队列（常见的有Kafka、Redis等），接着，Logstash Server（二级Logstash，主要用来拉取消息队列数据，过滤并分析数据）将格式化的数据传递给Elasticsearch进行存储。最后，由Kibana将日志和数据呈现给用户。由于引入了Kafka（或者Redis）缓存机制，即使远端Logstash Server因故障停止运行，数据也不会丢失，因为数据已经被存储下来了。
这种架构适合于较大集群、数据量一般的应用环境，但由于二级Logstash要分析处理大量数据，同时Elasticsearch也要存储和索引大量数据，因此它们的负荷会比较重，解决的方法是将它们配置为集群模式，以分担负载。
此架构的优点在于引入了消息队列机制，均衡了网络传输，从而降低了网络闭塞尤其是丢失数据的可能性，但依然存在Logstash占用系统资源过多的问题，在海量数据应用场景下，可能会出现性能瓶颈。
最后，还有第三种架构：
这个架构是在上面第二个架构基础上改进而来的，主要是将前端收集数据的Logstash Agent换成了Filebeat，消息队列使用了Kafka集群，然后将Logstash和Elasticsearch都通过集群模式进行构建，此架构适合大型集群、海量数据的业务场景，它通过将前端Logstash Agent替换成Filebeat，有效降低了收集日志对业务系统资源的消耗。同时，消息队列使用Kafka集群架构，有效保障了收集数据的安全性和稳定性，而后端Logstash和Elasticsearch均采用集群模式搭建，从整体上提高了ELK系统的高效性、扩展性和吞吐量。
#用大数据思维做运维监控
大数据分析最早就来源于运维人的日志分析，到逐渐发展对各种业务的分析，人们发现这些数据蕴涵着非常大的价值，通过实时监测、跟踪研究对象在互联网上产生的海量行为数据，进行挖掘分析，揭示出规律性的东西，提出研究结论和对策。这就是大数据的用途。
同样，通过大数据分析，我们可以得到各种指标，例如：
而这些指标，刚好是运维特别需要的东西。通过大数据分析出的这些指标，可以解决如下方面的问题：
* 系统健康状况监控
* 查找故障根源
* 系统瓶颈诊断和调优
* 追踪安全相关问题
那么如何用大数据思维做运维呢，大数据架构上的一个思维就是：提供一个平台让运维方便解决这些问题， 而不是，让大数据平台去解决出现的问题。
基本的一个大数据运维架构是这样的：
对于运维的监控，利用大数据思维，需要分三步走：
* 获取需要的数据
* 过滤出异常数据并设置告警阀值
* 通过第三方监控平台进行告警
所有系统最可靠的就是日志输出，系统是不是正常，发生了什么情况，我们以前是出了问题去查日志，或者自己写个脚本定时去分析。现在这些事情都可以整合到一个已有的平台上，我们唯一要做的就是定义分析日志的的逻辑。
好啦，这就是今天要给大家介绍的2019核心运维技能啦，抓住时机，开始全新学习吧！2019，你的全新开始！！！
原文链接：你有一份2019运维技能风向标，请查收（作者：高俊峰）
#运维职位的发展和趋势
根据不同的运维领域和技术面以及分工流程三个方面来了解下2019年运维职位的发展趋势。
##按领域来划分
- 基础设施运维：IDC/网络运维、服务器/存储设备运维
- 系统运维：系统中间件运维、云计算平台运维
- 数据运维：数据库运维、大数据技术平台运维
- 应用运维：应用软件系统
- 云平台运维：公有云平台运维
- 容器运维：基于容器服务的运维
##按技术切面来分
- 安全运维
- 性能运维
- 数据运维
- 集成运维
##按流程来划分
- 构建/持续集成、发布
- 安装部署、升级、迁移、合并、扩展
- 配置、初始化、配置变更
- 备份、传输、恢复
- 日志、监控、预警
- 诊断排查、优化
#系统运维技能图谱
系统运维是运维的基础，新的一年中，对基础运维技能要求也在提高，打好系统运维基础，才能深入学习后面的各种运维技能。
下图列出了系统运维要掌握的必备技能：
#Web运维技能图谱
Web运维是运维岗位中岗位最多的一个，薪资也相对较高，但需要掌握的知识点也比较多，新的技能要掌握，老的运维技能也不能丢，下图列出了Web运维要掌握的各种必备技能。
#大数据运维技能图谱
大数据从2017年开始逐渐走到生活的各个角落，2018年在逐渐落地，而在2019年，大数据依然火热，加上国家对大数据产业的扶持，大数据产业在新的一年岗位需求一定会更加大，因此掌握大数据运维技能，就走在了运维的前沿，下图列出了大数据运维要掌握的各种必备技能。
#容器运维技能图谱
容器的产生，是一次IT行业的革命，2015 年到 2016 年，是业界普遍认为的容器技术爆发的一年，短短一年多时间里，容器技术在中国大陆完成了从零星概念到烽火燎原的壮举。
时至今日，容器技术在国内大多数企业中落地已成为一种共识，而国内的生态系统，也呈现出了企业产品、开源社区和公有云齐头并进的良好局面。因此，2019年也是容器继续快速落地的一年，下图列出了大数据运维要掌握的各种必备技能。
#数据为王的时代
万丈高楼平地起，高楼稳不稳取决于地基是否扎实。运维数据便是运维管理这座高楼的地基。运维数据大致分为CMDB、日志、生产DB、知识库四个方面。
* CMDB中文是配置管理数据库，存储与管理企业IT架构中设备的各种配置信息，主要是IT资产管理信息。
* 日志数据保护了企业服务器上运行的各种系统产生的应用日志，系统日志、设备日志、数据库日志等数据，这部分数据是企业数据的核心。
* DB数据主要是所有IT系统的数据库信息，包括运维管理系统本身的数据库，数据库包含生产数据库、测试数据库、开发数据库三种类型。
* 知识库主要存储日常开发、测试、运维管理中发生的事件、问题以及一些经典问题的解决和常用的解决方案，主要起到运维管理辅助的功能。
对数据的维护和管理只管重要，特别是日志数据，对运维来说，通过日志可以比较准确全面地知道系统或是设备的运行情况，可以返查问题产生的原因，还原问题发生的整个过程。通过日志也可以提前预测系统可能要发生的问题或是故障，如系统安全日志，如果网络攻 击会在系统安全日志中有一定的体现。
下面简单介绍下，运维重点收集的日志数据有哪些部分以及用途。
##系统日志
系统日志主要指的是操作系统的日志，主要在/var/log下的各种日志信息。包含系统操作日志、系统安全日志、定时任务日志等。系统日志是运维管理安全模块中审计的重要依据。一般默认的操作系统日志不能满足要求，需要对系统的参数进行修改，如为history命令加上时间戳、IP，并且长久保留历史等功能。并且对日志文件进行处理，不允许用户进行清空命令，只能追加。
##应用日志
应用日志主要记录应用服务的健康运行情况以及业务操作的具体日志两部分。应用监控运行情况反应应用服务的健康状态，如果应用占用CPU或是内存过高或是忽高忽低不定，都可以通过分析应用日志结合业务操作日志得出结论。业务操作日志可以为业务审计提供主要依据。有一些系统喜欢把业务操作日志写到数据库中，这个也是需要注意的。不过不管在哪个地方，要求是不可缺少的，它为以后业务审计和问题返查提供依据。
##数据库日志
数据库日志主要反馈数据库的运行情况。通过监控和管理数据库的日志，及时了解数据库的运行情况，遇到问题及时解决等。可以通过数据库日志结合数据库系统自带的数据库如Oracle的系统视图v$开头，MySQL的performance_schema等。虽然数据库的一些信息不是存在日志中而是在数据库里面，但是也可以作为数据库日志的一部分进行管理和监控，已便我们及时知道数据库的监控状况，从而预防可能出现的问题。
##设备日志
设备日志一般是一个比较容易忽略的地方，但设备日志往往可以反映设备的运行情况。交换机故障，防火墙故障等设备故障都可能引起大面积的系统和服务故障。所以设备日志一定要收集，分析和监控预警。常用的设备日志有交换机日志、防火墙日志、网络安全设备日志等。
这么多的日志，运维要通过各种手段完成日志的收集、过滤分析、可视化展示，那么如何实现这些功能呢，方法很多，例如ELK集成套件（Elasticsearch，Logstash，Kibana）就可以轻松实现日志数据的实时收集、分析传输以及图形化展示。
* Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
* Logstash主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，Server端负责将收到的各节点日志进行过滤、修改等操作在一并发往Elasticsearch上去。
* Kibana也是一个开源和免费的工具，Kibana可以为Logstash和ElasticSearch提供的日志分析友好的Web界面，可以帮助汇总、分析和搜索重要数据日志。
另外，还有Filebeat可以替换Logstash作为日志收集工具，Filebeat隶属于Beats。目前Beats包含四种工具：
* Packetbeat（搜集网络流量数据）
* Topbeat（搜集系统、进程和文件系统级别的CPU和内存使用情况等数据）
* Filebeat（搜集文件数据）
* Winlogbeat（搜集Windows事件日志数据）
可以看到，Beats涵盖了所有收集日志数据的各个方面。
那么要如何使用ELK呢，根据日志量的不同，对应的ELK架构也不尽相同，看下面几个常见架构：
此架构主要是将Logstash部署在各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch再将数据以分片的形式压缩存储，并提供多种API供用户查询、操作。用户可以通过Kibana Web直观的对日志进行查询，并根据需求生成数据报表。
此架构的优点是搭建简单，易于上手。缺点是Logstash消耗系统资源比较大，运行时占用CPU和内存资源较高。另外，由于没有消息队列缓存，可能存在数据丢失的风险。此架构建议供初学者或数据量小的环境使用。
由此衍生出来了第二种架构：
此架构主要特点是引入了消息队列机制，位于各个节点上的Logstash Agent（一级Logstash，主要用来传输数据）先将数据传递给消息队列（常见的有Kafka、Redis等），接着，Logstash Server（二级Logstash，主要用来拉取消息队列数据，过滤并分析数据）将格式化的数据传递给Elasticsearch进行存储。最后，由Kibana将日志和数据呈现给用户。由于引入了Kafka（或者Redis）缓存机制，即使远端Logstash Server因故障停止运行，数据也不会丢失，因为数据已经被存储下来了。
这种架构适合于较大集群、数据量一般的应用环境，但由于二级Logstash要分析处理大量数据，同时Elasticsearch也要存储和索引大量数据，因此它们的负荷会比较重，解决的方法是将它们配置为集群模式，以分担负载。
此架构的优点在于引入了消息队列机制，均衡了网络传输，从而降低了网络闭塞尤其是丢失数据的可能性，但依然存在Logstash占用系统资源过多的问题，在海量数据应用场景下，可能会出现性能瓶颈。
最后，还有第三种架构：
这个架构是在上面第二个架构基础上改进而来的，主要是将前端收集数据的Logstash Agent换成了Filebeat，消息队列使用了Kafka集群，然后将Logstash和Elasticsearch都通过集群模式进行构建，此架构适合大型集群、海量数据的业务场景，它通过将前端Logstash Agent替换成Filebeat，有效降低了收集日志对业务系统资源的消耗。同时，消息队列使用Kafka集群架构，有效保障了收集数据的安全性和稳定性，而后端Logstash和Elasticsearch均采用集群模式搭建，从整体上提高了ELK系统的高效性、扩展性和吞吐量。
#用大数据思维做运维监控
大数据分析最早就来源于运维人的日志分析，到逐渐发展对各种业务的分析，人们发现这些数据蕴涵着非常大的价值，通过实时监测、跟踪研究对象在互联网上产生的海量行为数据，进行挖掘分析，揭示出规律性的东西，提出研究结论和对策。这就是大数据的用途。
同样，通过大数据分析，我们可以得到各种指标，例如：
- 在业务层面，如团购业务每秒访问数，团购券每秒验券数，每分钟支付、创建订单等
- 在应用层面，每个应用的错误数，调用过程，访问的平均耗时，最大耗时，95线等
- 在系统资源层面：如CPU、内存、Swap、磁盘、Load、主进程存活等
- 在网络层面： 如丢包、ping存活、流量、TCP连接数等
而这些指标，刚好是运维特别需要的东西。通过大数据分析出的这些指标，可以解决如下方面的问题：
* 系统健康状况监控
* 查找故障根源
* 系统瓶颈诊断和调优
* 追踪安全相关问题
那么如何用大数据思维做运维呢，大数据架构上的一个思维就是：提供一个平台让运维方便解决这些问题， 而不是，让大数据平台去解决出现的问题。
基本的一个大数据运维架构是这样的：
对于运维的监控，利用大数据思维，需要分三步走：
* 获取需要的数据
* 过滤出异常数据并设置告警阀值
* 通过第三方监控平台进行告警
所有系统最可靠的就是日志输出，系统是不是正常，发生了什么情况，我们以前是出了问题去查日志，或者自己写个脚本定时去分析。现在这些事情都可以整合到一个已有的平台上，我们唯一要做的就是定义分析日志的的逻辑。
好啦，这就是今天要给大家介绍的2019核心运维技能啦，抓住时机，开始全新学习吧！2019，你的全新开始！！！
原文链接：你有一份2019运维技能风向标，请查收（作者：高俊峰）
运维监控的终极秘籍
尼古拉斯 发表了文章 • 0 个评论 • 1341 次浏览 • 2019-02-14 17:54
有很多文章多次提到白盒监控和黑盒监控，以及监控的四个黄金指标。关于白盒与黑盒监控的定义，这里不再赘述。一般来说，白盒与黑盒分别从内部和外部来监控系统的运行状况，例如机器存活、CPU内存使用率、业务日志、JMX等监控都属于白盒监控，而外部端口探活、HTTP探测以 ...查看全部
有很多文章多次提到白盒监控和黑盒监控，以及监控的四个黄金指标。关于白盒与黑盒监控的定义，这里不再赘述。一般来说，白盒与黑盒分别从内部和外部来监控系统的运行状况，例如机器存活、CPU内存使用率、业务日志、JMX等监控都属于白盒监控，而外部端口探活、HTTP探测以及端到端功能监控等则属于黑盒监控的范畴。
本文将主要从白盒监控的采集入手，解答关于新系统如何添加监控的问题。
图 1 黑盒与白盒监控
#监控指标的采集
配置监控时，我们首要面对的是监控数据如何采集的问题。一般我们可以把监控指标分为两类：基础监控和业务监控。
##基础监控
包括CPU、内存、磁盘、端口和进程等机器、网络的操作系统级别的信息。通常情况下，成熟的监控系统（例如开源的Prometheus、Zabbix等）均会提供基础监控项的采集能力，这里不做过多介绍。但需要注意的一点，机器级别的基础监控指标一般并不能代表服务的真实运行状况，例如单台实例的故障对一个设计合理的分布式系统来说并不会带来严重后果。所以只有结合业务相关监控指标，基础监控指标才有意义。
##业务监控
业务监控指标由业务系统内部的服务产生，一般能够真实反应业务运行状态。设计合理的系统一般都会提供相关监控指标供监控系统采集。监控数据的采集方法一般可以分为以下几大类：
* 日志：日志可以包含服务运行的方方面面，是重要的监控数据来源。例如，通过Nginx access日志可以统计出错误（5xx）、延迟（响应时间）和流量，结合已知的容量上限就可以计算出饱和度。一般除监控系统提供的日志采集插件外，如Rsyslog、Logstash、Filebeat、Flume等都是比较优秀的日志采集软件
* JMX：多数Java开发的服务均可由JMX接口输出监控指标。不少监控系统也有集成JMX采集插件，除此之外我们也可通过jmxtrans、jmxcmd工具进行采集
* REST：提供REST API来进行监控数据的采集，如Hadoop、ElasticSearch
* OpenMetrics：得益于Prometheus的流行，作为Prometheus的监控数据采集方案，OpenMetrics可能很快会成为未来监控的业界标准。目前绝大部分热门开源服务均有官方或非官方的exporter可供使用
* 命令行：一些服务提供本地的命令来输出监控指标
* 主动上报：对于采用PUSH模型的监控系统来说，服务可以采取主动上报的方式把监控指标push到监控系统，如Java服务可使用Metrics接口自定义sink输出。另外，运维也可以使用自定义的监控插件来完成监控的采集
* 埋点：埋点是侵入式的监控数据采集方式，其优点是其可以更灵活地为我们提供业务内部的监控指标，当然缺点也很明显：需要在代码层面动手脚（常常需要研发支持，成本较高）
* 其它方式：以上未涵盖的监控指标采集方式，例如ZooKeeper的四字命令，MySQL的show status命令
以上列出了几种常见的监控指标采集方法，在实际工作，如果没有现成的监控采集插件，则需要我们自行开发采集脚本。
#四个黄金指标
图 2 四个黄金指标
无论业务系统如何复杂，监控指标如何眼花缭乱，但万变不离其宗，监控的目的无非是为了解服务运行状况、发现服务故障和帮助定位故障原因。为了达成这个目的，Google SRE总结的监控四个黄金指标对我们添加监控具有非常重要的指导意义。图 2给出四个黄金指标所包含的主要监控指标，下面我们就这四个黄金指标分别展开说明，并给出一些监控项的采集实例。
##错误：错误是指当前系统发生的错误请求和错误率
错误是需要在添加监控时首要关注的指标。
在添加错误相关监控时，我们应该关注以下几个方面：
基础监控：宕机、磁盘（坏盘或文件系统错误）、进程或端口挂掉、网络丢包等故障
业务监控：
* 核心功能处理错误，每种系统都有特定的核心功能，比如HDFS的文件块读写、Zookeeper对Key的读写和修改操作
* 基础功能单元丢失或异常，这里的基础功能单元是指一个系统功能上的基本单位，例如HDFS的Block、Kafka的Message，这种基础数据的丢失一般都会对业务功能造成直接的影响
* Master故障，对于中心化的分布式系统来说，Master的健康状况都是重中之重。例如HDFS的NameNode、ZooKeeper的Leader，ElasticSearch的MasterNode
* 可用节点数，对于分布式系统来说，可用节点数也是非常重要的，比如ZooKeeper、ETCD等系统需要满足可用节点数大于不可用节点数才能保证功能的正常
注意：除白盒监控外，主要功能或接口、以及内部存在明显边界的功能模块和上游依赖模块，都应该添加黑盒端到端监控。
##延迟：服务请求所需时间
服务延迟的上升不仅仅体现在用户体验的下降，也有可能会导致请求堆积并最终演变为整个业务系统的雪崩。以下为延迟指标的主要关注点：
* 基础监控：IO等待、网络延迟
* 业务监控：业务相关指标主要需要关注核心功能的响应时长。比如ZooKeeper的延迟指标zk_avg_latency，ElasticSearch的索引、搜索延迟和慢查询
注意：与错误指标类似，白盒延迟指标通常仅能代表系统内部延迟，建议为主要功能或接口添加黑盒监控来采集端到端的延迟指标。
##流量：当前系统的流量
流量指标可以指系统层面的网络和磁盘IO，服务层面的QpS、PV和UV等数据。流量和突增或突减都可能预示着系统可能出现问题（攻击事件、系统故障……）。
* 基础监控：磁盘和网卡IO
* 业务监控：核心功能流量，例如通过QpS/PV/UV等通常能够代表Web服务的流量，而ElasticSearch的流量可用索引创建速率、搜索速率表示
##饱和度：用于衡量当前服务的利用率
更为通俗的讲，饱和度可以理解为服务的利用率，可以代表系统承受的压力。所以饱和度与流量息息相关，流量的上升一般也会导致饱和度的上升。通常情况下，每种业务系统都应该有各自的饱和度指标。在很多业务系统中，消息队列长度是一个比较重要的饱和度指标，除此之外CPU、内存、磁盘、网络等系统资源利用率也可以作为饱和度的一种体现方式。
基础监控：CPU、内存、磁盘和网络利用率、内存堆栈利用率、文件句柄数、TCP连接数等
业务监控：
* 基础功能单元使用率，大多数系统对其基础的功能单元都有其处理能力的上限，接近或达到该上限时可能会导致服务的错误、延迟增大。例如HDFS的Block数量上升会导致NameNode堆内存使用率上升，Kafka的Topics和Partitions的数量、Zookeeper的node数的上升都会对系统产生压力
* 消息队列长度，不少系统采用消息队列存放待处理数据，所以消息队列长度在一定程度上可以代表系统的繁忙程度。如ElasticSearch、HDFS等都有队列长度相关指标可供采集
#总结
以上总结了常见的监控指标采集方法，以及四个黄金指标所包含的常见内容。在实际工作中，不同的监控系统的设计多种多样，没有统一标准，并且不同的业务系统通常也有着特定的监控采集方法和不同的黄金指标定义，具体如何采集监控指标和添加告警都需要我们针对不同系统特点灵活应对。
原文链接：运维监控的终极秘籍，盘它！
本文将主要从白盒监控的采集入手，解答关于新系统如何添加监控的问题。
图 1 黑盒与白盒监控
#监控指标的采集
配置监控时，我们首要面对的是监控数据如何采集的问题。一般我们可以把监控指标分为两类：基础监控和业务监控。
##基础监控
包括CPU、内存、磁盘、端口和进程等机器、网络的操作系统级别的信息。通常情况下，成熟的监控系统（例如开源的Prometheus、Zabbix等）均会提供基础监控项的采集能力，这里不做过多介绍。但需要注意的一点，机器级别的基础监控指标一般并不能代表服务的真实运行状况，例如单台实例的故障对一个设计合理的分布式系统来说并不会带来严重后果。所以只有结合业务相关监控指标，基础监控指标才有意义。
##业务监控
业务监控指标由业务系统内部的服务产生，一般能够真实反应业务运行状态。设计合理的系统一般都会提供相关监控指标供监控系统采集。监控数据的采集方法一般可以分为以下几大类：
* 日志：日志可以包含服务运行的方方面面，是重要的监控数据来源。例如，通过Nginx access日志可以统计出错误（5xx）、延迟（响应时间）和流量，结合已知的容量上限就可以计算出饱和度。一般除监控系统提供的日志采集插件外，如Rsyslog、Logstash、Filebeat、Flume等都是比较优秀的日志采集软件
* JMX：多数Java开发的服务均可由JMX接口输出监控指标。不少监控系统也有集成JMX采集插件，除此之外我们也可通过jmxtrans、jmxcmd工具进行采集
* REST：提供REST API来进行监控数据的采集，如Hadoop、ElasticSearch
* OpenMetrics：得益于Prometheus的流行，作为Prometheus的监控数据采集方案，OpenMetrics可能很快会成为未来监控的业界标准。目前绝大部分热门开源服务均有官方或非官方的exporter可供使用
* 命令行：一些服务提供本地的命令来输出监控指标
* 主动上报：对于采用PUSH模型的监控系统来说，服务可以采取主动上报的方式把监控指标push到监控系统，如Java服务可使用Metrics接口自定义sink输出。另外，运维也可以使用自定义的监控插件来完成监控的采集
* 埋点：埋点是侵入式的监控数据采集方式，其优点是其可以更灵活地为我们提供业务内部的监控指标，当然缺点也很明显：需要在代码层面动手脚（常常需要研发支持，成本较高）
* 其它方式：以上未涵盖的监控指标采集方式，例如ZooKeeper的四字命令，MySQL的show status命令
以上列出了几种常见的监控指标采集方法，在实际工作，如果没有现成的监控采集插件，则需要我们自行开发采集脚本。
#四个黄金指标
图 2 四个黄金指标
无论业务系统如何复杂，监控指标如何眼花缭乱，但万变不离其宗，监控的目的无非是为了解服务运行状况、发现服务故障和帮助定位故障原因。为了达成这个目的，Google SRE总结的监控四个黄金指标对我们添加监控具有非常重要的指导意义。图 2给出四个黄金指标所包含的主要监控指标，下面我们就这四个黄金指标分别展开说明，并给出一些监控项的采集实例。
##错误：错误是指当前系统发生的错误请求和错误率
错误是需要在添加监控时首要关注的指标。
在添加错误相关监控时，我们应该关注以下几个方面：
基础监控：宕机、磁盘（坏盘或文件系统错误）、进程或端口挂掉、网络丢包等故障
业务监控：
* 核心功能处理错误，每种系统都有特定的核心功能，比如HDFS的文件块读写、Zookeeper对Key的读写和修改操作
* 基础功能单元丢失或异常，这里的基础功能单元是指一个系统功能上的基本单位，例如HDFS的Block、Kafka的Message，这种基础数据的丢失一般都会对业务功能造成直接的影响
* Master故障，对于中心化的分布式系统来说，Master的健康状况都是重中之重。例如HDFS的NameNode、ZooKeeper的Leader，ElasticSearch的MasterNode
* 可用节点数，对于分布式系统来说，可用节点数也是非常重要的，比如ZooKeeper、ETCD等系统需要满足可用节点数大于不可用节点数才能保证功能的正常
注意：除白盒监控外，主要功能或接口、以及内部存在明显边界的功能模块和上游依赖模块，都应该添加黑盒端到端监控。
##延迟：服务请求所需时间
服务延迟的上升不仅仅体现在用户体验的下降，也有可能会导致请求堆积并最终演变为整个业务系统的雪崩。以下为延迟指标的主要关注点：
* 基础监控：IO等待、网络延迟
* 业务监控：业务相关指标主要需要关注核心功能的响应时长。比如ZooKeeper的延迟指标zk_avg_latency，ElasticSearch的索引、搜索延迟和慢查询
注意：与错误指标类似，白盒延迟指标通常仅能代表系统内部延迟，建议为主要功能或接口添加黑盒监控来采集端到端的延迟指标。
##流量：当前系统的流量
流量指标可以指系统层面的网络和磁盘IO，服务层面的QpS、PV和UV等数据。流量和突增或突减都可能预示着系统可能出现问题（攻击事件、系统故障……）。
* 基础监控：磁盘和网卡IO
* 业务监控：核心功能流量，例如通过QpS/PV/UV等通常能够代表Web服务的流量，而ElasticSearch的流量可用索引创建速率、搜索速率表示
##饱和度：用于衡量当前服务的利用率
更为通俗的讲，饱和度可以理解为服务的利用率，可以代表系统承受的压力。所以饱和度与流量息息相关，流量的上升一般也会导致饱和度的上升。通常情况下，每种业务系统都应该有各自的饱和度指标。在很多业务系统中，消息队列长度是一个比较重要的饱和度指标，除此之外CPU、内存、磁盘、网络等系统资源利用率也可以作为饱和度的一种体现方式。
基础监控：CPU、内存、磁盘和网络利用率、内存堆栈利用率、文件句柄数、TCP连接数等
业务监控：
* 基础功能单元使用率，大多数系统对其基础的功能单元都有其处理能力的上限，接近或达到该上限时可能会导致服务的错误、延迟增大。例如HDFS的Block数量上升会导致NameNode堆内存使用率上升，Kafka的Topics和Partitions的数量、Zookeeper的node数的上升都会对系统产生压力
* 消息队列长度，不少系统采用消息队列存放待处理数据，所以消息队列长度在一定程度上可以代表系统的繁忙程度。如ElasticSearch、HDFS等都有队列长度相关指标可供采集
#总结
以上总结了常见的监控指标采集方法，以及四个黄金指标所包含的常见内容。在实际工作中，不同的监控系统的设计多种多样，没有统一标准，并且不同的业务系统通常也有着特定的监控采集方法和不同的黄金指标定义，具体如何采集监控指标和添加告警都需要我们针对不同系统特点灵活应对。
原文链接：运维监控的终极秘籍，盘它！
DockOne微信分享（一零七）：SRE工程实践——基于时间序列存储数据的报警
Dataman数人科技 发表了文章 • 0 个评论 • 4264 次浏览 • 2017-02-22 17:12
【编者的话】构建智能运维平台，运行监控和故障报警是两个绕不过去的重要部分。本次分享主要是介绍引入SRE理念后的基于时间序列数据存储的报警工程实践。
#SRE报警介绍
今天我分享的主题是SRE基于时间序列数据的报警实践，既然是基于时间序列 ...查看全部
【编者的话】构建智能运维平台，运行监控和故障报警是两个绕不过去的重要部分。本次分享主要是介绍引入SRE理念后的基于时间序列数据存储的报警工程实践。
#SRE报警介绍
今天我分享的主题是SRE基于时间序列数据的报警实践，既然是基于时间序列。
首先，我先简单介绍一下什么是时间序列数据。
时间序列（time series）数据是一系列有序的数据。通常是等时间间隔的采样数据。时间序列存储最简单的定义就是数据格式里包含timestamp字段的数据。时间序列数据在查询时，对于时间序列总是会带上一个时间范围去过滤数据。同时查询的结果里也总是会包含timestamp字段。
监控数据大量呈现为时间序列数据特征，所以，为了应对复杂的监控数据格式，在每一份数据中加上时间字段。区别于传统的关系型数据库，时间序列数据的存储、查询和展现进行了专门的优化，从而获得极高的数据压缩能力、极优的查询性能，特别契合需要处理海量时间序列数据的物联网应用场景。
Google的监控系统经过10年的发展，经历了从传统的探针模型、图形化趋势展示的模型到现在基于时间序列数据信息进行监控报警的新模型。这个模型将收集时间序列信息作为监控系统的首要任务，同时发展了一种时间序列信息操作语言，通过使用该语言将数据转化为图标和报警取代了以前的探针脚本。
监控和报警是密不可分的两个部分，之前我们公司的CTO肖德时曾经做过关于基于时间序列数据监控实践的分享，在本次分享中就不重复介绍前面的监控部分，感兴趣的同学可以去看看老肖的文章。
运维团队通过监控系统了解应用服务的运行时状态，保障服务的可用性和稳定性。监控系统也通常会提供Dashboard展示服务运行的指标数据，虽然各种折线图看着很有趣，但是监控系统最有价值的体现，是当服务出现异常或指标值超过设定的阀值，运维团队收到报警消息，及时介入并恢复服务到正常状态的时候。
SRE团队认为监控系统不应该依赖人来分析报警信息，应该由系统自动分析，发出的报警要有可操作性，目标是解决某种已经发生的问题，或者是避免发生的问题。
#监控与报警
监控与报警可以让系统在发生故障或临近发生故障时主动通知我们。当系统无法自动修复某个问题时，需要一个人来调查这项警报，以决定目前是否存在真实故障，采取一定方法缓解故障，分析故障现象，最终找出导致故障的原因。监控系统应该从两个方面提供故障的信息，即现象和原因。
##黑盒监控与白盒监控
黑盒监控: 通过测试某种外部用户可见的系统行为进行监控。这是面向现象的监控，提供的是正在发生的问题，并向员工发出紧急警报。对于还没有发生，但是即将发生的问题，黑盒监控无能为力。
白盒监控依靠系统内部暴露的一些性能指标进行监控。包括日志分析，Java虚拟机提供的监控接口，或者一个列出内部统计数据的HTTP接口进行监控。白盒监控能够通过分析系统内部信息的指标值，可以检测到即将发生的问题。白盒监控有时是面向现象的，有时是面向原因的，这个取决于白盒监控提供的信息。
Google的SRE大量依赖于白盒监控。
##设置报警的几个原则
通常情况下，我们不应该仅仅因为“某个东西看起来有点问题”就发出警报。
紧急警报的处理会占用员工宝贵的时间，如果该员工在工作时间段，该报警的处理会打断他原本的工作流程。如果该员工在家，紧急警报的处理会影响他的个人生活。频繁的报警会让员工进入“狼来了”效应，怀疑警报的有效性和忽略报警，甚至错过了真实发生的故障。
设置报警规则的原则：
##监控报警组件
##搭建测试环境
为了方便测试，我们在测试服务器上用容器运行以上组件，测试服务器地址192.168.1.188。
1. 启动两个Nginx容器，并分配不同的label标识一个属于Dev组的应用，一个属于Ops组的应用。
2. 启动cAdvisor容器，端口映射8080。
3. 启动Alertmanager容器，端口映射9093，配置文件中指定Alerta的地址作为Webhook的通知地址。
4. 启动Prometheus容器，端口映射9090，CMD指定“-alertmanager.url”地址为Alertmanager的地址。
5. 启动MongoDB作为alerta的数据库
6. 启动Alerta，端口映射为8181
容器运行截图：
##应用指标收集
cAdvisor原生提供http接口暴露Prometheus需要收集的metrics，我们访问http://192.168.1.188:8080/metrics。
在Prometheus的配置文件里配置cAdvisor的地址作为target地址，可以在Prometheus的Web页面查看Targets的状态。
在Prometheus的Graph页面，可以对收集的数据进行查询和图形化展示。
##报警规则配置
我们针对容器应用的CPU使用率配置报警规则，规则如下：
图中分别针对dev组和ops组设置了应用容器的报警规则，报警规则的格式：
* “Alert”是报警规则的名字，名字间不能有空格，可以用下划线链接；
* “IF”是数据的查询表达式，截图中的语句内容查询指标“container_cpu_usage_seconds_total”，label “container_label_dataman_service”等于“web”，label “container_label_dataman_group” 等于“dev”，用函数irate()计算指标在上一个5分钟内每秒钟CPU使用时间的差值的比率。简单点说计算了CPU占用时间的百分比。这里两个报警规则中的表达式有点区别，是为了区分两个组的应用。
* “FOR”是报警状态持续超过1分钟后，将报警由状态“PENDING”改为“FIRING”，报警将交给Alertmanager处理。
* “LABELS”为自定义数据，我们在这里指定了报警的级别和显示“IF”中表达式的值。
* “ANNOTATIONS”为自定义数据，我们在这里提供报警的现象和原因介绍。
##触发报警
我们用stress对两个容器的CPU进行加压，使得容器的CPU使用率超过报警的阀值。在Prometheus的页面我们看到了产生的报警。
在Alertmanager页面看到从Prometheus发过来的报警。
可以看到Alertmanager还把报警消息推送给了alerta。
##报警消息展示
Alerta对接收到的报警进行保存并展示。
选择某条报警信息，可以进入详情，在详情页可以对报警进行Ack，关闭等操作。
报警结束后，可以在alerta中查看报警的历史，即处于关闭状态的报警。
#结束语
这里我们简要的介绍了下如何运用cAdvisor，Prometheus，Alertmanager和Alerta实现Google SRE中介绍的基于时序数据的报警实践，针对性能指标的报警只是最基础的报警方式，我们后续还会介绍如何配置和采集应用的内部数据指标，并进行监控报警的配置。应用系统的监控是一个复杂的过程，需要不断的调整以应对服务的运行状况和服务质量，也需要我们不断的吸取SRE的运维理念并在实践中落地。SRE可以说是DevOps在运维方面的具体实现，它既包括了理念、文化也包括了像监控报警这样具体的运维和工程实践。现在国内越来越多的企业开始关注SRE如何在整个生命周期为项目提供持续性支持。但是如何能够让SRE理念在本土落地，如何寻找到适合企业自身的SRE之路，数人云也在不断摸索并持续将现有的经验分享给大家，期望大家都能共同汲取SRE的营养以不断提升企业的运维和工程实践的水平。谢谢！
#Q&A
Q：告警信息收到后，系统有没有能力自动解决告警报告的问题？还是需要人工解决问题？谢谢
Q：InfluxDB系列方案是否有考虑，Grafana 最新版也有了很好的告警机制，是否有尝试？
Q：报警规则配置是什么语法，是否可以可视化？
Q：数据量庞大的情况怎么解决，比如说万台机器，500个指标数据等 一分钟一个点 60243050010000 的数据量，如何保存，如何快速查询数据。 需要什么样的架构和硬件？
Q：请问在监控报警方面有没有考虑或实践过智能预警，比如基于历史监控数据，通过机器学习，实现提前预警等？
Q：请问基于此方案部署的主机和容器规模有多大，基于什么频率进行监控收集？
Q：cAdvisor采集数据的性能表现怎么样，占用主机的资源大嘛？
Q：APP自身业务逻辑需要监控的数据，比如Counter，Gauge等，传统用Zabbix等可以进行数据采集。我明白cAdvisor是对Container进行数据采集。但是有没有可能把APP自身的监控和Container的监控结合？
以上内容根据2017年2月21日晚微信群分享内容整理。分享人窦中强，数人云研发工程师。多年运维开发经验，熟悉配置管理，持续集成等相关技术和实践，目前负责数人云平台监控报警组件的研发工作。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesz，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。
#SRE报警介绍
今天我分享的主题是SRE基于时间序列数据的报警实践，既然是基于时间序列。
首先，我先简单介绍一下什么是时间序列数据。
时间序列（time series）数据是一系列有序的数据。通常是等时间间隔的采样数据。时间序列存储最简单的定义就是数据格式里包含timestamp字段的数据。时间序列数据在查询时，对于时间序列总是会带上一个时间范围去过滤数据。同时查询的结果里也总是会包含timestamp字段。
监控数据大量呈现为时间序列数据特征，所以，为了应对复杂的监控数据格式，在每一份数据中加上时间字段。区别于传统的关系型数据库，时间序列数据的存储、查询和展现进行了专门的优化，从而获得极高的数据压缩能力、极优的查询性能，特别契合需要处理海量时间序列数据的物联网应用场景。
Google的监控系统经过10年的发展，经历了从传统的探针模型、图形化趋势展示的模型到现在基于时间序列数据信息进行监控报警的新模型。这个模型将收集时间序列信息作为监控系统的首要任务，同时发展了一种时间序列信息操作语言，通过使用该语言将数据转化为图标和报警取代了以前的探针脚本。
监控和报警是密不可分的两个部分，之前我们公司的CTO肖德时曾经做过关于基于时间序列数据监控实践的分享，在本次分享中就不重复介绍前面的监控部分，感兴趣的同学可以去看看老肖的文章。
运维团队通过监控系统了解应用服务的运行时状态，保障服务的可用性和稳定性。监控系统也通常会提供Dashboard展示服务运行的指标数据，虽然各种折线图看着很有趣，但是监控系统最有价值的体现，是当服务出现异常或指标值超过设定的阀值，运维团队收到报警消息，及时介入并恢复服务到正常状态的时候。
SRE团队认为监控系统不应该依赖人来分析报警信息，应该由系统自动分析，发出的报警要有可操作性，目标是解决某种已经发生的问题，或者是避免发生的问题。
#监控与报警
监控与报警可以让系统在发生故障或临近发生故障时主动通知我们。当系统无法自动修复某个问题时，需要一个人来调查这项警报，以决定目前是否存在真实故障，采取一定方法缓解故障，分析故障现象，最终找出导致故障的原因。监控系统应该从两个方面提供故障的信息，即现象和原因。
##黑盒监控与白盒监控
黑盒监控: 通过测试某种外部用户可见的系统行为进行监控。这是面向现象的监控，提供的是正在发生的问题，并向员工发出紧急警报。对于还没有发生，但是即将发生的问题，黑盒监控无能为力。
白盒监控依靠系统内部暴露的一些性能指标进行监控。包括日志分析，Java虚拟机提供的监控接口，或者一个列出内部统计数据的HTTP接口进行监控。白盒监控能够通过分析系统内部信息的指标值，可以检测到即将发生的问题。白盒监控有时是面向现象的，有时是面向原因的，这个取决于白盒监控提供的信息。
Google的SRE大量依赖于白盒监控。
##设置报警的几个原则
通常情况下，我们不应该仅仅因为“某个东西看起来有点问题”就发出警报。
紧急警报的处理会占用员工宝贵的时间，如果该员工在工作时间段，该报警的处理会打断他原本的工作流程。如果该员工在家，紧急警报的处理会影响他的个人生活。频繁的报警会让员工进入“狼来了”效应，怀疑警报的有效性和忽略报警，甚至错过了真实发生的故障。
设置报警规则的原则：
- 发出的警报必须是真实的，紧急的，重要的，可操作的。
- 报警规则要展示你的服务正在出现的问题或即将出现的问题。
- 清晰的问题分类，基本功能是否可用；响应时间；数据是否正确等。
- 对故障现象报警，并提供尽可能详细的细节和原因，不要直接对原因报警。
- cAdvisro为用户提供理解容器运行时的资源使用和性能特征的工具。cAdvisor作为一个后台运行的程序，收集，聚合，处理并导出容器运行时的信息。
- Prometheus是SoundCloud开发的开源的系统监控报警工具集。Prometheus从cAdvisor的HTTP接口采集容器运行时的信息，保存在内部的存储里，利用PromQL对时序数据进行查询展示和设置报警。报警信息推送到Alertmanager。
- Alertmanager处理由Prometheus服务发送过来的报警，进行去重，分组，路由，静默和降噪等操作。
- Alerta是一个用户友好的报警可视化展示工具，用于展示和管理从Alertmanager推送过来的报警数据。
##搭建测试环境
为了方便测试，我们在测试服务器上用容器运行以上组件，测试服务器地址192.168.1.188。
1. 启动两个Nginx容器，并分配不同的label标识一个属于Dev组的应用，一个属于Ops组的应用。
2. 启动cAdvisor容器，端口映射8080。
3. 启动Alertmanager容器，端口映射9093，配置文件中指定Alerta的地址作为Webhook的通知地址。
4. 启动Prometheus容器，端口映射9090，CMD指定“-alertmanager.url”地址为Alertmanager的地址。
5. 启动MongoDB作为alerta的数据库
6. 启动Alerta，端口映射为8181
容器运行截图：
##应用指标收集
cAdvisor原生提供http接口暴露Prometheus需要收集的metrics，我们访问http://192.168.1.188:8080/metrics。
在Prometheus的配置文件里配置cAdvisor的地址作为target地址，可以在Prometheus的Web页面查看Targets的状态。
在Prometheus的Graph页面，可以对收集的数据进行查询和图形化展示。
##报警规则配置
我们针对容器应用的CPU使用率配置报警规则，规则如下：
图中分别针对dev组和ops组设置了应用容器的报警规则，报警规则的格式：
* “Alert”是报警规则的名字，名字间不能有空格，可以用下划线链接；
* “IF”是数据的查询表达式，截图中的语句内容查询指标“container_cpu_usage_seconds_total”，label “container_label_dataman_service”等于“web”，label “container_label_dataman_group” 等于“dev”，用函数irate()计算指标在上一个5分钟内每秒钟CPU使用时间的差值的比率。简单点说计算了CPU占用时间的百分比。这里两个报警规则中的表达式有点区别，是为了区分两个组的应用。
* “FOR”是报警状态持续超过1分钟后，将报警由状态“PENDING”改为“FIRING”，报警将交给Alertmanager处理。
* “LABELS”为自定义数据，我们在这里指定了报警的级别和显示“IF”中表达式的值。
* “ANNOTATIONS”为自定义数据，我们在这里提供报警的现象和原因介绍。
##触发报警
我们用stress对两个容器的CPU进行加压，使得容器的CPU使用率超过报警的阀值。在Prometheus的页面我们看到了产生的报警。
在Alertmanager页面看到从Prometheus发过来的报警。
可以看到Alertmanager还把报警消息推送给了alerta。
##报警消息展示
Alerta对接收到的报警进行保存并展示。
选择某条报警信息，可以进入详情，在详情页可以对报警进行Ack，关闭等操作。
报警结束后，可以在alerta中查看报警的历史，即处于关闭状态的报警。
#结束语
这里我们简要的介绍了下如何运用cAdvisor，Prometheus，Alertmanager和Alerta实现Google SRE中介绍的基于时序数据的报警实践，针对性能指标的报警只是最基础的报警方式，我们后续还会介绍如何配置和采集应用的内部数据指标，并进行监控报警的配置。应用系统的监控是一个复杂的过程，需要不断的调整以应对服务的运行状况和服务质量，也需要我们不断的吸取SRE的运维理念并在实践中落地。SRE可以说是DevOps在运维方面的具体实现，它既包括了理念、文化也包括了像监控报警这样具体的运维和工程实践。现在国内越来越多的企业开始关注SRE如何在整个生命周期为项目提供持续性支持。但是如何能够让SRE理念在本土落地，如何寻找到适合企业自身的SRE之路，数人云也在不断摸索并持续将现有的经验分享给大家，期望大家都能共同汲取SRE的营养以不断提升企业的运维和工程实践的水平。谢谢！
#Q&A
Q：告警信息收到后，系统有没有能力自动解决告警报告的问题？还是需要人工解决问题？谢谢
A：这个要分情况，好的机制是报警应该发出的是新的问题，然后通过反馈机制，让同类的问题不再发生，或者由监控系统自身解决。
Q：InfluxDB系列方案是否有考虑，Grafana 最新版也有了很好的告警机制，是否有尝试？
A：曾经考虑并实践过InfluxDB的TICK组合方案，非常方便可以实现数据收集存储处理展示的完整流程。通过对比，我们发现Prometheus更符合Google SRE对于监控的理念，自身社区也非常活跃，就转向Prometheus的方案了。Grafana实现了强大的可视化配置报警规则的功能，对于原本只做为展示的工具，是很好的增强，这个对我们的启发也很大，也在学习中。
Q：报警规则配置是什么语法，是否可以可视化？
A：Prometheus是在配置文件中描述报警规则。可以自己动手实现可视化。
Q：数据量庞大的情况怎么解决，比如说万台机器，500个指标数据等 一分钟一个点 60243050010000 的数据量，如何保存，如何快速查询数据。 需要什么样的架构和硬件？
A：简单回答，Prometheus可以通过分组支持大规模的集群，但是达到某个确定的规模，那就需要实践给出答案了。
Q：请问在监控报警方面有没有考虑或实践过智能预警，比如基于历史监控数据，通过机器学习，实现提前预警等？
A：这个不是SRE推荐的方式，报警应该简单，高级的功能会模糊真实的意图。
Q：请问基于此方案部署的主机和容器规模有多大，基于什么频率进行监控收集？
A：本次分享的是测试环境，规模不大。Prometheus定时从cAdvisor收集数据，抓取频率5s。
Q：cAdvisor采集数据的性能表现怎么样，占用主机的资源大嘛？
A：性能表现优异，担心占用资源，可以在启动容器时进行资源限制。
Q：APP自身业务逻辑需要监控的数据，比如Counter，Gauge等，传统用Zabbix等可以进行数据采集。我明白cAdvisor是对Container进行数据采集。但是有没有可能把APP自身的监控和Container的监控结合？
A：后续话题，我们会实践有关应用的监控报警。Prometheus的逻辑是定时从exporter抓取数据，然后对存储的时序数据，通过PromQL进行查询和分析，所以是可以实现APP自身的监控和容器监控的结合的。
以上内容根据2017年2月21日晚微信群分享内容整理。分享人窦中强，数人云研发工程师。多年运维开发经验，熟悉配置管理，持续集成等相关技术和实践，目前负责数人云平台监控报警组件的研发工作。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesz，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。
运维平台信用分——滴滴内部的数据驱动实践
老马 发表了文章 • 0 个评论 • 164 次浏览 • 2019-05-25 21:03
【编者的话】在大家的印象中，运维人员更多的是从属业务的角色。在传统的企业IT中，没有快速的产品迭代，没有每天成百上千次的服务发布和伸缩容，这样的角色看似没有问题。但在如今的 DevOps 时代，日常的运维工作中每天要应对成百上千次的服务发布与线上操作。如果运维 ...查看全部
【编者的话】在大家的印象中，运维人员更多的是从属业务的角色。在传统的企业IT中，没有快速的产品迭代，没有每天成百上千次的服务发布和伸缩容，这样的角色看似没有问题。但在如今的 DevOps 时代，日常的运维工作中每天要应对成百上千次的服务发布与线上操作。如果运维人员（即SRE）仍然只是被动的去应对这种变化，所造成的结果，必然是疲于应付，最终会对全平台的业务稳定性造成很大隐患。
那么，在这种量变引起质变的挑战中，运维人员应该发挥怎样的作用，才能适应新业务的挑战呢？笔者之前曾就职于IBM Cloud部门，现在就职于滴滴运维部，长期从事自动化运维方面的工作，下面就结合自己之前的经验和目前的工作，谈谈自己的一些见解。如果你想和更多运维技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
#来自业务的挑战
无论是在滴滴还是在之前的部门，在业务发展的初期阶段，都不可避免的经历了粗犷型的扩张阶段，比如业务量指数级上升，用户量急剧增加，每时每刻都有服务模块的迭代。
在业务优先的前提下，运维人员承担着巨大的运维压力。以监控为例，用户添加监控不规范，会造成报警频发，报警有效性不足，导致的后果就是容易让真正有价值的报警湮没在海量数据中，同时，也会造成对报警资源的浪费，比如，研发同学不区分测试、线上环境，随意的添加报警采集指标，会对监控系统的存储，查询带来极大的挑战。再比如部署系统，不按照规范，在高峰期更新服务，一旦出问题，会造成整个应用的服务不可用。这样的例子有很多。
#如何应对
如果上述的问题一直延续下去，运维工作必然带来巨大的挑战，并且会严重影响线上服务的稳定性。面对这些问题，滴滴运维团队的同学也在一起思考，运维应该不仅仅去被动的适应业务，而是要从平台稳定性出发，去指导研发同学，如何规范的执行变更，如何合理的使用监控资源以及其它公司IT基础设施。
我们想到的解决方法就是“数据说话”，尽可能的去量化监控、部署及基础组件（MySQL、Codis、ZooKeeper）的使用。然后用数字去指导研发的同学，尽可能的去匹配我们给出的“最佳实践”，从而减少造成线上业务不稳定的隐患。
所以，滴滴运维部推出了“风险量化平台”，包含“变更信用分”（用来度量服务的变更操作，比如服务部署上线，配置变更等）、“监控健康分”（用来度量用户对报警监控的使用），从而打造一个“看得见的手”，驱动业务同学来一起提高线上稳定性。
##数据驱动的难点有三个方面
首先是如何获取数据？这是“风险量化平台”的基础。使用监控系统，部署一个服务，执行一次配置变更，都是一个个用户操作，很难用数字去表达。为此我们结合运维经验，基于对操作每个步骤的详尽输出，近可能的去用数字维度来衡量用户操作。比如以部署为例，会以灰度发布中间的暂停时间是否满足一定时长，是否有在上线高峰期操作记录，部署过程中是否执行了double-check，在哪个阶段执行了回滚等等，来形成一个个的打分项。
其次是如何去制定风险量化的标准，也就是如何用各个指标去构造一个最佳实践。这更像是一个数学建模，里面涉及到大量的运维经验积累，以我们新推出的监控健康分为例，我们遵循着“有服务必有监控，有报警必须处理”的原则，对于每个服务，要求衡量的标准包括，是否有存活指标监控（进程、端口等）；是否有基础指标监控（如cpu.idle，mem.used，disk.used）；是否添加了上下游监控，报警是否有效，即报警接收人是否过多（因为大家都收到报警，最终的结果，往往意味着大家都不会处理报警），报警是否被及时处理（运维领域也有MTTA， MTTR，即报警平均响应时间，和报警及时处理时间这样的概念）；是否配置了监控大盘，方便我们日常巡检。
各个量化项目占据不同的权重（如下方的监控健康分剖析图）， 比如我们根据滴滴目前的服务特点，存活指标占比40%， 报警有效性占比30%，推动业务去收敛报警，和完善监控。监控健康分以80分为及格线，寻找出监控漏洞，并指导用户加以改进。 用这样的方法，可以让研发同学尽可能的减少漏配监控的事情发生，提高线上服务的稳定性。
最后的难点是如何驱动？这是我们现在着力想的一个点。风险量化实际上就是总结前人踩过的坑，趟过的雷，去告诉后面的同学，提前来规避风险，这是运维部门对公司业务稳定性的一大贡献。
现在已有的做法是如下图（各部门变更信用分排名图）所示，通过计算、打分、全公司各个业务线排名，将风险量化数据和反应出的问题推送给各个业务线的leader。以竞赛方式去推动各个业务线重视风险量化。我们还计划以监控健康分去驱动报警有效性的建设，完善报警值班制度，避免群发报警又无人处理，报警配置不合理这种现象的发生。
#效果如何
目前的风险量化体系包含“变更信用分”，“监控健康分”，其中变更信用分已经上线一年多了，在2018年，从下图能明显看到信用分在稳步上升。
带来结果是什么呢？ 下面是本年度故障case统计图，能明显的看到这种趋势，故障case数量随着变更信用分的提高在稳步下降。考虑到同时期的变更数量也在一直增加，这种下降趋势就更加明显了。
我们期望其它的信用分机制，也能给业务稳定性带来这样积极的结果。
#未来展望
对于未来的展望，首先希望能对尽可能多的涉及线上操作的内容进行风险量化，比如业务使用的中间件／基础组件，业务中涉及安全的服务是否遵循了相应的规范，是否有密码／数据泄漏风险。
其次，我们仍然需要对已有的运维经验进行总结，结合经验，利用量化分数去构建“最佳实践”，指导大家去遵守。
最后是如何去驱动，将总结的数据价值，最大化的发挥出来。
原文链接：https://mp.weixin.qq.com/s/AYjpv2GSYDLl0pB9tHqkrg
那么，在这种量变引起质变的挑战中，运维人员应该发挥怎样的作用，才能适应新业务的挑战呢？笔者之前曾就职于IBM Cloud部门，现在就职于滴滴运维部，长期从事自动化运维方面的工作，下面就结合自己之前的经验和目前的工作，谈谈自己的一些见解。如果你想和更多运维技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
#来自业务的挑战
无论是在滴滴还是在之前的部门，在业务发展的初期阶段，都不可避免的经历了粗犷型的扩张阶段，比如业务量指数级上升，用户量急剧增加，每时每刻都有服务模块的迭代。
在业务优先的前提下，运维人员承担着巨大的运维压力。以监控为例，用户添加监控不规范，会造成报警频发，报警有效性不足，导致的后果就是容易让真正有价值的报警湮没在海量数据中，同时，也会造成对报警资源的浪费，比如，研发同学不区分测试、线上环境，随意的添加报警采集指标，会对监控系统的存储，查询带来极大的挑战。再比如部署系统，不按照规范，在高峰期更新服务，一旦出问题，会造成整个应用的服务不可用。这样的例子有很多。
#如何应对
如果上述的问题一直延续下去，运维工作必然带来巨大的挑战，并且会严重影响线上服务的稳定性。面对这些问题，滴滴运维团队的同学也在一起思考，运维应该不仅仅去被动的适应业务，而是要从平台稳定性出发，去指导研发同学，如何规范的执行变更，如何合理的使用监控资源以及其它公司IT基础设施。
我们想到的解决方法就是“数据说话”，尽可能的去量化监控、部署及基础组件（MySQL、Codis、ZooKeeper）的使用。然后用数字去指导研发的同学，尽可能的去匹配我们给出的“最佳实践”，从而减少造成线上业务不稳定的隐患。
所以，滴滴运维部推出了“风险量化平台”，包含“变更信用分”（用来度量服务的变更操作，比如服务部署上线，配置变更等）、“监控健康分”（用来度量用户对报警监控的使用），从而打造一个“看得见的手”，驱动业务同学来一起提高线上稳定性。
##数据驱动的难点有三个方面
首先是如何获取数据？这是“风险量化平台”的基础。使用监控系统，部署一个服务，执行一次配置变更，都是一个个用户操作，很难用数字去表达。为此我们结合运维经验，基于对操作每个步骤的详尽输出，近可能的去用数字维度来衡量用户操作。比如以部署为例，会以灰度发布中间的暂停时间是否满足一定时长，是否有在上线高峰期操作记录，部署过程中是否执行了double-check，在哪个阶段执行了回滚等等，来形成一个个的打分项。
其次是如何去制定风险量化的标准，也就是如何用各个指标去构造一个最佳实践。这更像是一个数学建模，里面涉及到大量的运维经验积累，以我们新推出的监控健康分为例，我们遵循着“有服务必有监控，有报警必须处理”的原则，对于每个服务，要求衡量的标准包括，是否有存活指标监控（进程、端口等）；是否有基础指标监控（如cpu.idle，mem.used，disk.used）；是否添加了上下游监控，报警是否有效，即报警接收人是否过多（因为大家都收到报警，最终的结果，往往意味着大家都不会处理报警），报警是否被及时处理（运维领域也有MTTA， MTTR，即报警平均响应时间，和报警及时处理时间这样的概念）；是否配置了监控大盘，方便我们日常巡检。
各个量化项目占据不同的权重（如下方的监控健康分剖析图）， 比如我们根据滴滴目前的服务特点，存活指标占比40%， 报警有效性占比30%，推动业务去收敛报警，和完善监控。监控健康分以80分为及格线，寻找出监控漏洞，并指导用户加以改进。 用这样的方法，可以让研发同学尽可能的减少漏配监控的事情发生，提高线上服务的稳定性。
最后的难点是如何驱动？这是我们现在着力想的一个点。风险量化实际上就是总结前人踩过的坑，趟过的雷，去告诉后面的同学，提前来规避风险，这是运维部门对公司业务稳定性的一大贡献。
现在已有的做法是如下图（各部门变更信用分排名图）所示，通过计算、打分、全公司各个业务线排名，将风险量化数据和反应出的问题推送给各个业务线的leader。以竞赛方式去推动各个业务线重视风险量化。我们还计划以监控健康分去驱动报警有效性的建设，完善报警值班制度，避免群发报警又无人处理，报警配置不合理这种现象的发生。
#效果如何
目前的风险量化体系包含“变更信用分”，“监控健康分”，其中变更信用分已经上线一年多了，在2018年，从下图能明显看到信用分在稳步上升。
带来结果是什么呢？ 下面是本年度故障case统计图，能明显的看到这种趋势，故障case数量随着变更信用分的提高在稳步下降。考虑到同时期的变更数量也在一直增加，这种下降趋势就更加明显了。
我们期望其它的信用分机制，也能给业务稳定性带来这样积极的结果。
#未来展望
对于未来的展望，首先希望能对尽可能多的涉及线上操作的内容进行风险量化，比如业务使用的中间件／基础组件，业务中涉及安全的服务是否遵循了相应的规范，是否有密码／数据泄漏风险。
其次，我们仍然需要对已有的运维经验进行总结，结合经验，利用量化分数去构建“最佳实践”，指导大家去遵守。
最后是如何去驱动，将总结的数据价值，最大化的发挥出来。
原文链接：https://mp.weixin.qq.com/s/AYjpv2GSYDLl0pB9tHqkrg
运维工程师不得不看的经验教训和注意事项
大卫 发表了文章 • 0 个评论 • 222 次浏览 • 2019-05-22 19:48
#一、线上操作规范
##测试使用
当初学习Linux的使用，从基础到服务到集群，都是在虚拟机做的，虽然老师告诉我们跟真机没有什么差别，可是对真实环境的渴望日渐上升，不过虚拟机的各种快照却让我们养成了各种手贱的习惯，以致于拿到服务器操作权 ...查看全部
#一、线上操作规范
##测试使用
当初学习Linux的使用，从基础到服务到集群，都是在虚拟机做的，虽然老师告诉我们跟真机没有什么差别，可是对真实环境的渴望日渐上升，不过虚拟机的各种快照却让我们养成了各种手贱的习惯，以致于拿到服务器操作权限时候，就迫不及待的想去试试，记得上班第一天，老大把root密码交给我，由于只能使用putty，我就想使用xshell，于是悄悄登录服务器尝试改为xshell+密钥登录，因为没有测试，也没有留一个ssh连接，所有重启sshd服务器之后，自己就被挡在服务器之外了，幸好当时我备份了sshd_config文件，后来让机房人员cp过去就可以了，幸亏这是一家小公司，不然直接就被干了……庆幸当年运气比较好。如果你想和更多运维技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
第二个例子是关于文件同步的，大家都知道rsync同步很快，可是他删除文件的速度大大超过了rm -rf，在rsync中有一个命令是，以某目录为准同步某文件（如果第一个目录是空的，那么结果可想而知），源目录（有数据的）就会被删除，当初我就是因为误操作，以及缺乏测试，就目录写反了，关键是没有备份……生产环境数据被删了
没备份，大家自己想后果吧，其重要性不言而喻。
##Enter前再三确认
关于rm -rf / var这种错误，我相信手快的人，或者网速比较慢的时候，出现的几率相当大
当你发现执行完之后，你的心至少是凉了半截。
大家可能会说，我按了这么多次都没出过错，不用怕，我只想说当出现一次你就明白了，不要以为那些运维事故都是在别人身上，如果你不注意，下一个就是你。
##切忌多人操作
我在的上一家公司，运维管理相当混乱，举一个最典型的例子吧，离职好几任的运维都有服务器root密码。
通常我们运维接到任务，都会进行简单查看如果无法解决，就请求他人帮忙，可是当问题焦头烂额的时候，客服主管（懂点Linux），网管，你上司一起调试一个服务器，当你各种百度,各种对照，完了发现，你的服务器配置文件，跟上次你修改不一样了，然后再改回来，然后再谷歌，兴冲冲发现问题，解决了，别人却告诉你，他也解决了，修改的是不同的参数……这个，我就真不知道哪个是问题真正的原因了，当然这还是好的，问题解决了，皆大欢喜，可是你遇到过你刚修改的文件，测试无效，再去修改发现文件又被修改的时候呢？真的很恼火，切忌多人操作。
##先备份后操作
养成一个习惯，要修改数据时，先备份，比如.conf的配置文件。另外，修改配置文件时，建议注释原选项，然后再复制，修改，再者说，如果第一个例子中，有数据库备份，那rsync的误操作不久没事了吧。所以说丢数据库非一朝一夕，随便备份一个就不用那么惨。
#二、涉及数据
##慎用rm -rf
网上的例子很多，各种rm -rf /，各种删除主数据库，各种运维事故……
一点小失误就会造成很大的损失。如果真需要删除，一定要谨慎。
##备份大于一切
本来上面都有各种关于备份，但是我想把它划分在数据类再次强调，备份非常之重要哇。我记得我的老师说过一句话，涉及到数据何种的谨慎都不为过。我就职的公司有做第三方支付网站和网贷平台的，第三方支付是每两个小时完全备份一次，网贷平台是每20分钟备份一次，我不多说了，大家自己斟酌吧。
##稳定大于一切
其实不止是数据，在整个服务器环境，都是稳定大于一切，不求最快，但求最稳定，求可用性。所以未经测试，不要再服务器使用新的软件，比如Nginx+php-fpm，生产环境中PHP各种挂啊。重启下就好了，或者换apache就好了。
##保密大于一切
现在各种艳照门漫天飞，各种路由器后门，所以说，涉及到数据，不保密是不行的。
##三、涉及安全
##SSH
* 更改默认端口（当然如果专业要黑你，扫描下就出来了）
* 禁止root登录
* 使用普通用户+key认证+sudo规则+IP地址+用户限制
* 使用hostdeny类似的防爆里破解软件（超过几次尝试直接拉黑）
* 筛选/etc/passwd中login的用户
##防火墙
防火墙生产环境一定要开，并且要遵循最小原则，drop所有，然后放行需要的服务端口。
##精细权限和控制粒度
能使用普通用户启动的服务坚决不使用root，把各种服务权限控制到最低，控制粒度要精细。
##入侵检测和日志监控
* 使用第三方软件，时刻检测系统关键文件以及各种服务配置文件的改动，比如：/etc/passwd，/etc/my.cnf，/etc/httpd/con/httpd.con等；
* 使用集中化的日志监控体系，监控/var/log/secure，/etc/log/message，ftp上传下载文件等报警错误日志；
* 另外针对端口扫描，也可以使用一些第三方软件，发现被扫描就直接拉入host.deny。这些信息对于系统被入侵后排错很有帮助。有人说过，一个公司在安全投入的成本跟他被安全攻击损失的成本成正比，安全是一个很大的话题。
也是一个很基础的工作，把基础做好了，就能相当的提高系统安全性，其他的就是安全高手做的了
#四、日常监控
##系统运行监控
好多人踏入运维都是从监控做起，大的公司一般都有专业24小时监控运维。系统运行监控一般包括硬件占用率，常见的有：内存，硬盘，CPU，网卡，os包括登录监控，系统关键文件监控。
定期的监控可以预测出硬件损坏的概率，并且给调优带来很实用的功能
##服务运行监控
服务监控一般就是各种应用，Web，DB，LVS等，这一般都是监控一些指标。
在系统出现性能瓶颈的时候就能很快发现并解决。
##日志监控
这里的日志监控跟安全的日志监控类似，但这里一般都是硬件，os，应用程序的报错和警报信息。
监控在系统稳定运行的时候确实没啥用，但是一旦出现问题，你又没做监控，就会很被动了。
#五、性能调优
##深入了解运行机制
其实按一年多的运维经验来说，谈调优根本就是纸上谈兵，但是我只是想简单总结下，如果有更深入的了解，我会更新。在对软件进行优化之前，比如要深入了解一个软件的运行机制，比如Nginx和Apache，大家都说Nginx快，那就必须知道Nginx为什么快，利用什么原理，处理请求比Apache，并且要能跟别人用浅显易懂的话说出来，必要的时候还要能看懂源代码，否则一切以参数为调优对象的文档都是瞎谈。
##调优框架以及先后
熟悉了底层运行机制，就要有调优的框架和先后顺序，比如数据库出现瓶颈，好多人直接就去更改数据库的配置文件，我的建议是，先根据瓶颈去分析，查看日志，写出来调优方向，然后再入手，并且数据库服务器调优应该是最后一步，最先的应该是硬件和操作系统，现在的数据库服务器都是在各种测试之后才会发布的。
适用于所有操作系统，不应该先从他入手。
##每次只调一个参数
每次只调一个参数，这个相比大家都了解，调的多了，你就自己就迷糊了。
##基准测试
判断调优是否有用，和测试一个新版本软件的稳定性和性能等方面，就必须要基准测试了，测试要涉及很多因素。
测试是否接近业务真实需求这要看测试人的经验了，相关资料大家可以参考《高性能MySQL》第三版相当的好。
我的老师曾说过，没有放之四海皆准的参数，任何参数更改任何调优都必须符合业务场景，所以不要再谷歌什么什么调优了，对你的提升和业务环境的改善没有长久作用
#六、运维心态
##控制心态
很多rm -rf /data都在下班的前几分钟，都在烦躁的高峰，那么你还不打算控制下你的心态么？
有人说了，烦躁也要上班，可是你可以在烦躁的时候尽量避免处理关键数据环境。
越是有压力，越要冷静，不然会损失更多。
大多人都有rm -rf /data/mysql的经历，发现删除之后，那种心情你可以想象一下，可是如果没有备份，你急又有什么用，一般这种情况下，你就要冷静想下最坏打算了，对于MySQL来说，删除了物理文件，一部分表还会存在内存中，所以断开业务，但是不要关闭mysql数据库，这对恢复很有帮助，并使用dd复制硬盘，然后你再进行恢复。
当然了大多时候你就只能找数据恢复公司了。
试想一下，数据被删了，你各种操作，关闭数据库，然后修复，不但有可能覆盖文件，还找不到内存中的表了。
##对数据负责
生产环境不是儿戏，数据库也不是儿戏，一定要对数据负责。不备份的后果是非常严重的。
##追根究底
很多运维人员比较忙，遇到问题解决就不会再管了，记得去年一个客户的网站老是打不开，经过PHP代码报错。
发现是session和whos_online损坏，前任运维是通过repair修复的，我就也这样修复了，但是过了几个小时，又出现了。
反复三四次之后，我就去谷歌数据库表莫名损坏原因：一是MyISAM的bug，二是mysqlbug，三是MySQL在写入过程中
被kill，最后发现是内存不够用，导致OOM kill了mysqld进程。
并且没有swap分区，后台监控内存是够用的，最后升级物理内存解决。
##测试和生产环境
在重要操作之前一定要看自己所在的机器，尽量避免多开窗口。
原文链接：http://www.cnblogs.com/yihr/p/9593795.html
##测试使用
当初学习Linux的使用，从基础到服务到集群，都是在虚拟机做的，虽然老师告诉我们跟真机没有什么差别，可是对真实环境的渴望日渐上升，不过虚拟机的各种快照却让我们养成了各种手贱的习惯，以致于拿到服务器操作权限时候，就迫不及待的想去试试，记得上班第一天，老大把root密码交给我，由于只能使用putty，我就想使用xshell，于是悄悄登录服务器尝试改为xshell+密钥登录，因为没有测试，也没有留一个ssh连接，所有重启sshd服务器之后，自己就被挡在服务器之外了，幸好当时我备份了sshd_config文件，后来让机房人员cp过去就可以了，幸亏这是一家小公司，不然直接就被干了……庆幸当年运气比较好。如果你想和更多运维技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
第二个例子是关于文件同步的，大家都知道rsync同步很快，可是他删除文件的速度大大超过了rm -rf，在rsync中有一个命令是，以某目录为准同步某文件（如果第一个目录是空的，那么结果可想而知），源目录（有数据的）就会被删除，当初我就是因为误操作，以及缺乏测试，就目录写反了，关键是没有备份……生产环境数据被删了
没备份，大家自己想后果吧，其重要性不言而喻。
##Enter前再三确认
关于rm -rf / var这种错误，我相信手快的人，或者网速比较慢的时候，出现的几率相当大
当你发现执行完之后，你的心至少是凉了半截。
大家可能会说，我按了这么多次都没出过错，不用怕，我只想说当出现一次你就明白了，不要以为那些运维事故都是在别人身上，如果你不注意，下一个就是你。
##切忌多人操作
我在的上一家公司，运维管理相当混乱，举一个最典型的例子吧，离职好几任的运维都有服务器root密码。
通常我们运维接到任务，都会进行简单查看如果无法解决，就请求他人帮忙，可是当问题焦头烂额的时候，客服主管（懂点Linux），网管，你上司一起调试一个服务器，当你各种百度,各种对照，完了发现，你的服务器配置文件，跟上次你修改不一样了，然后再改回来，然后再谷歌，兴冲冲发现问题，解决了，别人却告诉你，他也解决了，修改的是不同的参数……这个，我就真不知道哪个是问题真正的原因了，当然这还是好的，问题解决了，皆大欢喜，可是你遇到过你刚修改的文件，测试无效，再去修改发现文件又被修改的时候呢？真的很恼火，切忌多人操作。
##先备份后操作
养成一个习惯，要修改数据时，先备份，比如.conf的配置文件。另外，修改配置文件时，建议注释原选项，然后再复制，修改，再者说，如果第一个例子中，有数据库备份，那rsync的误操作不久没事了吧。所以说丢数据库非一朝一夕，随便备份一个就不用那么惨。
#二、涉及数据
##慎用rm -rf
网上的例子很多，各种rm -rf /，各种删除主数据库，各种运维事故……
一点小失误就会造成很大的损失。如果真需要删除，一定要谨慎。
##备份大于一切
本来上面都有各种关于备份，但是我想把它划分在数据类再次强调，备份非常之重要哇。我记得我的老师说过一句话，涉及到数据何种的谨慎都不为过。我就职的公司有做第三方支付网站和网贷平台的，第三方支付是每两个小时完全备份一次，网贷平台是每20分钟备份一次，我不多说了，大家自己斟酌吧。
##稳定大于一切
其实不止是数据，在整个服务器环境，都是稳定大于一切，不求最快，但求最稳定，求可用性。所以未经测试，不要再服务器使用新的软件，比如Nginx+php-fpm，生产环境中PHP各种挂啊。重启下就好了，或者换apache就好了。
##保密大于一切
现在各种艳照门漫天飞，各种路由器后门，所以说，涉及到数据，不保密是不行的。
##三、涉及安全
##SSH
* 更改默认端口（当然如果专业要黑你，扫描下就出来了）
* 禁止root登录
* 使用普通用户+key认证+sudo规则+IP地址+用户限制
* 使用hostdeny类似的防爆里破解软件（超过几次尝试直接拉黑）
* 筛选/etc/passwd中login的用户
##防火墙
防火墙生产环境一定要开，并且要遵循最小原则，drop所有，然后放行需要的服务端口。
##精细权限和控制粒度
能使用普通用户启动的服务坚决不使用root，把各种服务权限控制到最低，控制粒度要精细。
##入侵检测和日志监控
* 使用第三方软件，时刻检测系统关键文件以及各种服务配置文件的改动，比如：/etc/passwd，/etc/my.cnf，/etc/httpd/con/httpd.con等；
* 使用集中化的日志监控体系，监控/var/log/secure，/etc/log/message，ftp上传下载文件等报警错误日志；
* 另外针对端口扫描，也可以使用一些第三方软件，发现被扫描就直接拉入host.deny。这些信息对于系统被入侵后排错很有帮助。有人说过，一个公司在安全投入的成本跟他被安全攻击损失的成本成正比，安全是一个很大的话题。
也是一个很基础的工作，把基础做好了，就能相当的提高系统安全性，其他的就是安全高手做的了
#四、日常监控
##系统运行监控
好多人踏入运维都是从监控做起，大的公司一般都有专业24小时监控运维。系统运行监控一般包括硬件占用率，常见的有：内存，硬盘，CPU，网卡，os包括登录监控，系统关键文件监控。
定期的监控可以预测出硬件损坏的概率，并且给调优带来很实用的功能
##服务运行监控
服务监控一般就是各种应用，Web，DB，LVS等，这一般都是监控一些指标。
在系统出现性能瓶颈的时候就能很快发现并解决。
##日志监控
这里的日志监控跟安全的日志监控类似，但这里一般都是硬件，os，应用程序的报错和警报信息。
监控在系统稳定运行的时候确实没啥用，但是一旦出现问题，你又没做监控，就会很被动了。
#五、性能调优
##深入了解运行机制
其实按一年多的运维经验来说，谈调优根本就是纸上谈兵，但是我只是想简单总结下，如果有更深入的了解，我会更新。在对软件进行优化之前，比如要深入了解一个软件的运行机制，比如Nginx和Apache，大家都说Nginx快，那就必须知道Nginx为什么快，利用什么原理，处理请求比Apache，并且要能跟别人用浅显易懂的话说出来，必要的时候还要能看懂源代码，否则一切以参数为调优对象的文档都是瞎谈。
##调优框架以及先后
熟悉了底层运行机制，就要有调优的框架和先后顺序，比如数据库出现瓶颈，好多人直接就去更改数据库的配置文件，我的建议是，先根据瓶颈去分析，查看日志，写出来调优方向，然后再入手，并且数据库服务器调优应该是最后一步，最先的应该是硬件和操作系统，现在的数据库服务器都是在各种测试之后才会发布的。
适用于所有操作系统，不应该先从他入手。
##每次只调一个参数
每次只调一个参数，这个相比大家都了解，调的多了，你就自己就迷糊了。
##基准测试
判断调优是否有用，和测试一个新版本软件的稳定性和性能等方面，就必须要基准测试了，测试要涉及很多因素。
测试是否接近业务真实需求这要看测试人的经验了，相关资料大家可以参考《高性能MySQL》第三版相当的好。
我的老师曾说过，没有放之四海皆准的参数，任何参数更改任何调优都必须符合业务场景，所以不要再谷歌什么什么调优了，对你的提升和业务环境的改善没有长久作用
#六、运维心态
##控制心态
很多rm -rf /data都在下班的前几分钟，都在烦躁的高峰，那么你还不打算控制下你的心态么？
有人说了，烦躁也要上班，可是你可以在烦躁的时候尽量避免处理关键数据环境。
越是有压力，越要冷静，不然会损失更多。
大多人都有rm -rf /data/mysql的经历，发现删除之后，那种心情你可以想象一下，可是如果没有备份，你急又有什么用，一般这种情况下，你就要冷静想下最坏打算了，对于MySQL来说，删除了物理文件，一部分表还会存在内存中，所以断开业务，但是不要关闭mysql数据库，这对恢复很有帮助，并使用dd复制硬盘，然后你再进行恢复。
当然了大多时候你就只能找数据恢复公司了。
试想一下，数据被删了，你各种操作，关闭数据库，然后修复，不但有可能覆盖文件，还找不到内存中的表了。
##对数据负责
生产环境不是儿戏，数据库也不是儿戏，一定要对数据负责。不备份的后果是非常严重的。
##追根究底
很多运维人员比较忙，遇到问题解决就不会再管了，记得去年一个客户的网站老是打不开，经过PHP代码报错。
发现是session和whos_online损坏，前任运维是通过repair修复的，我就也这样修复了，但是过了几个小时，又出现了。
反复三四次之后，我就去谷歌数据库表莫名损坏原因：一是MyISAM的bug，二是mysqlbug，三是MySQL在写入过程中
被kill，最后发现是内存不够用，导致OOM kill了mysqld进程。
并且没有swap分区，后台监控内存是够用的，最后升级物理内存解决。
##测试和生产环境
在重要操作之前一定要看自己所在的机器，尽量避免多开窗口。
原文链接：http://www.cnblogs.com/yihr/p/9593795.html
2019运维技能风向标
尼古拉斯 发表了文章 • 0 个评论 • 257 次浏览 • 2019-05-20 09:04
运维是一个融合多学科（网络、系统、开发、安全、应用架构、存储等）的综合性技术岗位，从最初的网络管理（网管）发展到现在的系统运维工程师、网络运维工程师、安全运维工程师、运维开发工程师等，可以看出，运维的分工一直在细化，并且对综合技能要求越来越高，可以看出，未来运 ...查看全部
运维是一个融合多学科（网络、系统、开发、安全、应用架构、存储等）的综合性技术岗位，从最初的网络管理（网管）发展到现在的系统运维工程师、网络运维工程师、安全运维工程师、运维开发工程师等，可以看出，运维的分工一直在细化，并且对综合技能要求越来越高，可以看出，未来运维的发展趋势是高、精、尖，高表示高度，精表示精通，尖表示尖端，也就是运维职场一定要站在一定的技术高度，在多个技术领域中，要精通某项技能，同时对尖端前沿技术一定要能掌控趋势。如果你想和更多运维技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
#运维职位的发展和趋势
根据不同的运维领域和技术面以及分工流程三个方面来了解下2019年运维职位的发展趋势。
##按领域来划分
##按技术切面来分
##按流程来划分
#系统运维技能图谱
系统运维是运维的基础，新的一年中，对基础运维技能要求也在提高，打好系统运维基础，才能深入学习后面的各种运维技能。
下图列出了系统运维要掌握的必备技能：
#Web运维技能图谱
Web运维是运维岗位中岗位最多的一个，薪资也相对较高，但需要掌握的知识点也比较多，新的技能要掌握，老的运维技能也不能丢，下图列出了Web运维要掌握的各种必备技能。
#大数据运维技能图谱
大数据从2017年开始逐渐走到生活的各个角落，2018年在逐渐落地，而在2019年，大数据依然火热，加上国家对大数据产业的扶持，大数据产业在新的一年岗位需求一定会更加大，因此掌握大数据运维技能，就走在了运维的前沿，下图列出了大数据运维要掌握的各种必备技能。
#容器运维技能图谱
容器的产生，是一次IT行业的革命，2015 年到 2016 年，是业界普遍认为的容器技术爆发的一年，短短一年多时间里，容器技术在中国大陆完成了从零星概念到烽火燎原的壮举。
时至今日，容器技术在国内大多数企业中落地已成为一种共识，而国内的生态系统，也呈现出了企业产品、开源社区和公有云齐头并进的良好局面。因此，2019年也是容器继续快速落地的一年，下图列出了大数据运维要掌握的各种必备技能。
#数据为王的时代
万丈高楼平地起，高楼稳不稳取决于地基是否扎实。运维数据便是运维管理这座高楼的地基。运维数据大致分为CMDB、日志、生产DB、知识库四个方面。
* CMDB中文是配置管理数据库，存储与管理企业IT架构中设备的各种配置信息，主要是IT资产管理信息。
* 日志数据保护了企业服务器上运行的各种系统产生的应用日志，系统日志、设备日志、数据库日志等数据，这部分数据是企业数据的核心。
* DB数据主要是所有IT系统的数据库信息，包括运维管理系统本身的数据库，数据库包含生产数据库、测试数据库、开发数据库三种类型。
* 知识库主要存储日常开发、测试、运维管理中发生的事件、问题以及一些经典问题的解决和常用的解决方案，主要起到运维管理辅助的功能。
对数据的维护和管理只管重要，特别是日志数据，对运维来说，通过日志可以比较准确全面地知道系统或是设备的运行情况，可以返查问题产生的原因，还原问题发生的整个过程。通过日志也可以提前预测系统可能要发生的问题或是故障，如系统安全日志，如果网络攻 击会在系统安全日志中有一定的体现。
下面简单介绍下，运维重点收集的日志数据有哪些部分以及用途。
##系统日志
系统日志主要指的是操作系统的日志，主要在/var/log下的各种日志信息。包含系统操作日志、系统安全日志、定时任务日志等。系统日志是运维管理安全模块中审计的重要依据。一般默认的操作系统日志不能满足要求，需要对系统的参数进行修改，如为history命令加上时间戳、IP，并且长久保留历史等功能。并且对日志文件进行处理，不允许用户进行清空命令，只能追加。
##应用日志
应用日志主要记录应用服务的健康运行情况以及业务操作的具体日志两部分。应用监控运行情况反应应用服务的健康状态，如果应用占用CPU或是内存过高或是忽高忽低不定，都可以通过分析应用日志结合业务操作日志得出结论。业务操作日志可以为业务审计提供主要依据。有一些系统喜欢把业务操作日志写到数据库中，这个也是需要注意的。不过不管在哪个地方，要求是不可缺少的，它为以后业务审计和问题返查提供依据。
##数据库日志
数据库日志主要反馈数据库的运行情况。通过监控和管理数据库的日志，及时了解数据库的运行情况，遇到问题及时解决等。可以通过数据库日志结合数据库系统自带的数据库如Oracle的系统视图v$开头，MySQL的performance_schema等。虽然数据库的一些信息不是存在日志中而是在数据库里面，但是也可以作为数据库日志的一部分进行管理和监控，已便我们及时知道数据库的监控状况，从而预防可能出现的问题。
##设备日志
设备日志一般是一个比较容易忽略的地方，但设备日志往往可以反映设备的运行情况。交换机故障，防火墙故障等设备故障都可能引起大面积的系统和服务故障。所以设备日志一定要收集，分析和监控预警。常用的设备日志有交换机日志、防火墙日志、网络安全设备日志等。
这么多的日志，运维要通过各种手段完成日志的收集、过滤分析、可视化展示，那么如何实现这些功能呢，方法很多，例如ELK集成套件（Elasticsearch，Logstash，Kibana）就可以轻松实现日志数据的实时收集、分析传输以及图形化展示。
* Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
* Logstash主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，Server端负责将收到的各节点日志进行过滤、修改等操作在一并发往Elasticsearch上去。
* Kibana也是一个开源和免费的工具，Kibana可以为Logstash和ElasticSearch提供的日志分析友好的Web界面，可以帮助汇总、分析和搜索重要数据日志。
另外，还有Filebeat可以替换Logstash作为日志收集工具，Filebeat隶属于Beats。目前Beats包含四种工具：
* Packetbeat（搜集网络流量数据）
* Topbeat（搜集系统、进程和文件系统级别的CPU和内存使用情况等数据）
* Filebeat（搜集文件数据）
* Winlogbeat（搜集Windows事件日志数据）
可以看到，Beats涵盖了所有收集日志数据的各个方面。
那么要如何使用ELK呢，根据日志量的不同，对应的ELK架构也不尽相同，看下面几个常见架构：
此架构主要是将Logstash部署在各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch再将数据以分片的形式压缩存储，并提供多种API供用户查询、操作。用户可以通过Kibana Web直观的对日志进行查询，并根据需求生成数据报表。
此架构的优点是搭建简单，易于上手。缺点是Logstash消耗系统资源比较大，运行时占用CPU和内存资源较高。另外，由于没有消息队列缓存，可能存在数据丢失的风险。此架构建议供初学者或数据量小的环境使用。
由此衍生出来了第二种架构：
此架构主要特点是引入了消息队列机制，位于各个节点上的Logstash Agent（一级Logstash，主要用来传输数据）先将数据传递给消息队列（常见的有Kafka、Redis等），接着，Logstash Server（二级Logstash，主要用来拉取消息队列数据，过滤并分析数据）将格式化的数据传递给Elasticsearch进行存储。最后，由Kibana将日志和数据呈现给用户。由于引入了Kafka（或者Redis）缓存机制，即使远端Logstash Server因故障停止运行，数据也不会丢失，因为数据已经被存储下来了。
这种架构适合于较大集群、数据量一般的应用环境，但由于二级Logstash要分析处理大量数据，同时Elasticsearch也要存储和索引大量数据，因此它们的负荷会比较重，解决的方法是将它们配置为集群模式，以分担负载。
此架构的优点在于引入了消息队列机制，均衡了网络传输，从而降低了网络闭塞尤其是丢失数据的可能性，但依然存在Logstash占用系统资源过多的问题，在海量数据应用场景下，可能会出现性能瓶颈。
最后，还有第三种架构：
这个架构是在上面第二个架构基础上改进而来的，主要是将前端收集数据的Logstash Agent换成了Filebeat，消息队列使用了Kafka集群，然后将Logstash和Elasticsearch都通过集群模式进行构建，此架构适合大型集群、海量数据的业务场景，它通过将前端Logstash Agent替换成Filebeat，有效降低了收集日志对业务系统资源的消耗。同时，消息队列使用Kafka集群架构，有效保障了收集数据的安全性和稳定性，而后端Logstash和Elasticsearch均采用集群模式搭建，从整体上提高了ELK系统的高效性、扩展性和吞吐量。
#用大数据思维做运维监控
大数据分析最早就来源于运维人的日志分析，到逐渐发展对各种业务的分析，人们发现这些数据蕴涵着非常大的价值，通过实时监测、跟踪研究对象在互联网上产生的海量行为数据，进行挖掘分析，揭示出规律性的东西，提出研究结论和对策。这就是大数据的用途。
同样，通过大数据分析，我们可以得到各种指标，例如：
而这些指标，刚好是运维特别需要的东西。通过大数据分析出的这些指标，可以解决如下方面的问题：
* 系统健康状况监控
* 查找故障根源
* 系统瓶颈诊断和调优
* 追踪安全相关问题
那么如何用大数据思维做运维呢，大数据架构上的一个思维就是：提供一个平台让运维方便解决这些问题， 而不是，让大数据平台去解决出现的问题。
基本的一个大数据运维架构是这样的：
对于运维的监控，利用大数据思维，需要分三步走：
* 获取需要的数据
* 过滤出异常数据并设置告警阀值
* 通过第三方监控平台进行告警
所有系统最可靠的就是日志输出，系统是不是正常，发生了什么情况，我们以前是出了问题去查日志，或者自己写个脚本定时去分析。现在这些事情都可以整合到一个已有的平台上，我们唯一要做的就是定义分析日志的的逻辑。
好啦，这就是今天要给大家介绍的2019核心运维技能啦，抓住时机，开始全新学习吧！2019，你的全新开始！！！
原文链接：你有一份2019运维技能风向标，请查收（作者：高俊峰）
#运维职位的发展和趋势
根据不同的运维领域和技术面以及分工流程三个方面来了解下2019年运维职位的发展趋势。
##按领域来划分
- 基础设施运维：IDC/网络运维、服务器/存储设备运维
- 系统运维：系统中间件运维、云计算平台运维
- 数据运维：数据库运维、大数据技术平台运维
- 应用运维：应用软件系统
- 云平台运维：公有云平台运维
- 容器运维：基于容器服务的运维
##按技术切面来分
- 安全运维
- 性能运维
- 数据运维
- 集成运维
##按流程来划分
- 构建/持续集成、发布
- 安装部署、升级、迁移、合并、扩展
- 配置、初始化、配置变更
- 备份、传输、恢复
- 日志、监控、预警
- 诊断排查、优化
#系统运维技能图谱
系统运维是运维的基础，新的一年中，对基础运维技能要求也在提高，打好系统运维基础，才能深入学习后面的各种运维技能。
下图列出了系统运维要掌握的必备技能：
#Web运维技能图谱
Web运维是运维岗位中岗位最多的一个，薪资也相对较高，但需要掌握的知识点也比较多，新的技能要掌握，老的运维技能也不能丢，下图列出了Web运维要掌握的各种必备技能。
#大数据运维技能图谱
大数据从2017年开始逐渐走到生活的各个角落，2018年在逐渐落地，而在2019年，大数据依然火热，加上国家对大数据产业的扶持，大数据产业在新的一年岗位需求一定会更加大，因此掌握大数据运维技能，就走在了运维的前沿，下图列出了大数据运维要掌握的各种必备技能。
#容器运维技能图谱
容器的产生，是一次IT行业的革命，2015 年到 2016 年，是业界普遍认为的容器技术爆发的一年，短短一年多时间里，容器技术在中国大陆完成了从零星概念到烽火燎原的壮举。
时至今日，容器技术在国内大多数企业中落地已成为一种共识，而国内的生态系统，也呈现出了企业产品、开源社区和公有云齐头并进的良好局面。因此，2019年也是容器继续快速落地的一年，下图列出了大数据运维要掌握的各种必备技能。
#数据为王的时代
万丈高楼平地起，高楼稳不稳取决于地基是否扎实。运维数据便是运维管理这座高楼的地基。运维数据大致分为CMDB、日志、生产DB、知识库四个方面。
* CMDB中文是配置管理数据库，存储与管理企业IT架构中设备的各种配置信息，主要是IT资产管理信息。
* 日志数据保护了企业服务器上运行的各种系统产生的应用日志，系统日志、设备日志、数据库日志等数据，这部分数据是企业数据的核心。
* DB数据主要是所有IT系统的数据库信息，包括运维管理系统本身的数据库，数据库包含生产数据库、测试数据库、开发数据库三种类型。
* 知识库主要存储日常开发、测试、运维管理中发生的事件、问题以及一些经典问题的解决和常用的解决方案，主要起到运维管理辅助的功能。
对数据的维护和管理只管重要，特别是日志数据，对运维来说，通过日志可以比较准确全面地知道系统或是设备的运行情况，可以返查问题产生的原因，还原问题发生的整个过程。通过日志也可以提前预测系统可能要发生的问题或是故障，如系统安全日志，如果网络攻 击会在系统安全日志中有一定的体现。
下面简单介绍下，运维重点收集的日志数据有哪些部分以及用途。
##系统日志
系统日志主要指的是操作系统的日志，主要在/var/log下的各种日志信息。包含系统操作日志、系统安全日志、定时任务日志等。系统日志是运维管理安全模块中审计的重要依据。一般默认的操作系统日志不能满足要求，需要对系统的参数进行修改，如为history命令加上时间戳、IP，并且长久保留历史等功能。并且对日志文件进行处理，不允许用户进行清空命令，只能追加。
##应用日志
应用日志主要记录应用服务的健康运行情况以及业务操作的具体日志两部分。应用监控运行情况反应应用服务的健康状态，如果应用占用CPU或是内存过高或是忽高忽低不定，都可以通过分析应用日志结合业务操作日志得出结论。业务操作日志可以为业务审计提供主要依据。有一些系统喜欢把业务操作日志写到数据库中，这个也是需要注意的。不过不管在哪个地方，要求是不可缺少的，它为以后业务审计和问题返查提供依据。
##数据库日志
数据库日志主要反馈数据库的运行情况。通过监控和管理数据库的日志，及时了解数据库的运行情况，遇到问题及时解决等。可以通过数据库日志结合数据库系统自带的数据库如Oracle的系统视图v$开头，MySQL的performance_schema等。虽然数据库的一些信息不是存在日志中而是在数据库里面，但是也可以作为数据库日志的一部分进行管理和监控，已便我们及时知道数据库的监控状况，从而预防可能出现的问题。
##设备日志
设备日志一般是一个比较容易忽略的地方，但设备日志往往可以反映设备的运行情况。交换机故障，防火墙故障等设备故障都可能引起大面积的系统和服务故障。所以设备日志一定要收集，分析和监控预警。常用的设备日志有交换机日志、防火墙日志、网络安全设备日志等。
这么多的日志，运维要通过各种手段完成日志的收集、过滤分析、可视化展示，那么如何实现这些功能呢，方法很多，例如ELK集成套件（Elasticsearch，Logstash，Kibana）就可以轻松实现日志数据的实时收集、分析传输以及图形化展示。
* Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
* Logstash主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，Server端负责将收到的各节点日志进行过滤、修改等操作在一并发往Elasticsearch上去。
* Kibana也是一个开源和免费的工具，Kibana可以为Logstash和ElasticSearch提供的日志分析友好的Web界面，可以帮助汇总、分析和搜索重要数据日志。
另外，还有Filebeat可以替换Logstash作为日志收集工具，Filebeat隶属于Beats。目前Beats包含四种工具：
* Packetbeat（搜集网络流量数据）
* Topbeat（搜集系统、进程和文件系统级别的CPU和内存使用情况等数据）
* Filebeat（搜集文件数据）
* Winlogbeat（搜集Windows事件日志数据）
可以看到，Beats涵盖了所有收集日志数据的各个方面。
那么要如何使用ELK呢，根据日志量的不同，对应的ELK架构也不尽相同，看下面几个常见架构：
此架构主要是将Logstash部署在各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch再将数据以分片的形式压缩存储，并提供多种API供用户查询、操作。用户可以通过Kibana Web直观的对日志进行查询，并根据需求生成数据报表。
此架构的优点是搭建简单，易于上手。缺点是Logstash消耗系统资源比较大，运行时占用CPU和内存资源较高。另外，由于没有消息队列缓存，可能存在数据丢失的风险。此架构建议供初学者或数据量小的环境使用。
由此衍生出来了第二种架构：
此架构主要特点是引入了消息队列机制，位于各个节点上的Logstash Agent（一级Logstash，主要用来传输数据）先将数据传递给消息队列（常见的有Kafka、Redis等），接着，Logstash Server（二级Logstash，主要用来拉取消息队列数据，过滤并分析数据）将格式化的数据传递给Elasticsearch进行存储。最后，由Kibana将日志和数据呈现给用户。由于引入了Kafka（或者Redis）缓存机制，即使远端Logstash Server因故障停止运行，数据也不会丢失，因为数据已经被存储下来了。
这种架构适合于较大集群、数据量一般的应用环境，但由于二级Logstash要分析处理大量数据，同时Elasticsearch也要存储和索引大量数据，因此它们的负荷会比较重，解决的方法是将它们配置为集群模式，以分担负载。
此架构的优点在于引入了消息队列机制，均衡了网络传输，从而降低了网络闭塞尤其是丢失数据的可能性，但依然存在Logstash占用系统资源过多的问题，在海量数据应用场景下，可能会出现性能瓶颈。
最后，还有第三种架构：
这个架构是在上面第二个架构基础上改进而来的，主要是将前端收集数据的Logstash Agent换成了Filebeat，消息队列使用了Kafka集群，然后将Logstash和Elasticsearch都通过集群模式进行构建，此架构适合大型集群、海量数据的业务场景，它通过将前端Logstash Agent替换成Filebeat，有效降低了收集日志对业务系统资源的消耗。同时，消息队列使用Kafka集群架构，有效保障了收集数据的安全性和稳定性，而后端Logstash和Elasticsearch均采用集群模式搭建，从整体上提高了ELK系统的高效性、扩展性和吞吐量。
#用大数据思维做运维监控
大数据分析最早就来源于运维人的日志分析，到逐渐发展对各种业务的分析，人们发现这些数据蕴涵着非常大的价值，通过实时监测、跟踪研究对象在互联网上产生的海量行为数据，进行挖掘分析，揭示出规律性的东西，提出研究结论和对策。这就是大数据的用途。
同样，通过大数据分析，我们可以得到各种指标，例如：
- 在业务层面，如团购业务每秒访问数，团购券每秒验券数，每分钟支付、创建订单等
- 在应用层面，每个应用的错误数，调用过程，访问的平均耗时，最大耗时，95线等
- 在系统资源层面：如CPU、内存、Swap、磁盘、Load、主进程存活等
- 在网络层面： 如丢包、ping存活、流量、TCP连接数等
而这些指标，刚好是运维特别需要的东西。通过大数据分析出的这些指标，可以解决如下方面的问题：
* 系统健康状况监控
* 查找故障根源
* 系统瓶颈诊断和调优
* 追踪安全相关问题
那么如何用大数据思维做运维呢，大数据架构上的一个思维就是：提供一个平台让运维方便解决这些问题， 而不是，让大数据平台去解决出现的问题。
基本的一个大数据运维架构是这样的：
对于运维的监控，利用大数据思维，需要分三步走：
* 获取需要的数据
* 过滤出异常数据并设置告警阀值
* 通过第三方监控平台进行告警
所有系统最可靠的就是日志输出，系统是不是正常，发生了什么情况，我们以前是出了问题去查日志，或者自己写个脚本定时去分析。现在这些事情都可以整合到一个已有的平台上，我们唯一要做的就是定义分析日志的的逻辑。
好啦，这就是今天要给大家介绍的2019核心运维技能啦，抓住时机，开始全新学习吧！2019，你的全新开始！！！
原文链接：你有一份2019运维技能风向标，请查收（作者：高俊峰）
运维监控的终极秘籍
尼古拉斯 发表了文章 • 0 个评论 • 1341 次浏览 • 2019-02-14 17:54
有很多文章多次提到白盒监控和黑盒监控，以及监控的四个黄金指标。关于白盒与黑盒监控的定义，这里不再赘述。一般来说，白盒与黑盒分别从内部和外部来监控系统的运行状况，例如机器存活、CPU内存使用率、业务日志、JMX等监控都属于白盒监控，而外部端口探活、HTTP探测以 ...查看全部
有很多文章多次提到白盒监控和黑盒监控，以及监控的四个黄金指标。关于白盒与黑盒监控的定义，这里不再赘述。一般来说，白盒与黑盒分别从内部和外部来监控系统的运行状况，例如机器存活、CPU内存使用率、业务日志、JMX等监控都属于白盒监控，而外部端口探活、HTTP探测以及端到端功能监控等则属于黑盒监控的范畴。
本文将主要从白盒监控的采集入手，解答关于新系统如何添加监控的问题。
图 1 黑盒与白盒监控
#监控指标的采集
配置监控时，我们首要面对的是监控数据如何采集的问题。一般我们可以把监控指标分为两类：基础监控和业务监控。
##基础监控
包括CPU、内存、磁盘、端口和进程等机器、网络的操作系统级别的信息。通常情况下，成熟的监控系统（例如开源的Prometheus、Zabbix等）均会提供基础监控项的采集能力，这里不做过多介绍。但需要注意的一点，机器级别的基础监控指标一般并不能代表服务的真实运行状况，例如单台实例的故障对一个设计合理的分布式系统来说并不会带来严重后果。所以只有结合业务相关监控指标，基础监控指标才有意义。
##业务监控
业务监控指标由业务系统内部的服务产生，一般能够真实反应业务运行状态。设计合理的系统一般都会提供相关监控指标供监控系统采集。监控数据的采集方法一般可以分为以下几大类：
* 日志：日志可以包含服务运行的方方面面，是重要的监控数据来源。例如，通过Nginx access日志可以统计出错误（5xx）、延迟（响应时间）和流量，结合已知的容量上限就可以计算出饱和度。一般除监控系统提供的日志采集插件外，如Rsyslog、Logstash、Filebeat、Flume等都是比较优秀的日志采集软件
* JMX：多数Java开发的服务均可由JMX接口输出监控指标。不少监控系统也有集成JMX采集插件，除此之外我们也可通过jmxtrans、jmxcmd工具进行采集
* REST：提供REST API来进行监控数据的采集，如Hadoop、ElasticSearch
* OpenMetrics：得益于Prometheus的流行，作为Prometheus的监控数据采集方案，OpenMetrics可能很快会成为未来监控的业界标准。目前绝大部分热门开源服务均有官方或非官方的exporter可供使用
* 命令行：一些服务提供本地的命令来输出监控指标
* 主动上报：对于采用PUSH模型的监控系统来说，服务可以采取主动上报的方式把监控指标push到监控系统，如Java服务可使用Metrics接口自定义sink输出。另外，运维也可以使用自定义的监控插件来完成监控的采集
* 埋点：埋点是侵入式的监控数据采集方式，其优点是其可以更灵活地为我们提供业务内部的监控指标，当然缺点也很明显：需要在代码层面动手脚（常常需要研发支持，成本较高）
* 其它方式：以上未涵盖的监控指标采集方式，例如ZooKeeper的四字命令，MySQL的show status命令
以上列出了几种常见的监控指标采集方法，在实际工作，如果没有现成的监控采集插件，则需要我们自行开发采集脚本。
#四个黄金指标
图 2 四个黄金指标
无论业务系统如何复杂，监控指标如何眼花缭乱，但万变不离其宗，监控的目的无非是为了解服务运行状况、发现服务故障和帮助定位故障原因。为了达成这个目的，Google SRE总结的监控四个黄金指标对我们添加监控具有非常重要的指导意义。图 2给出四个黄金指标所包含的主要监控指标，下面我们就这四个黄金指标分别展开说明，并给出一些监控项的采集实例。
##错误：错误是指当前系统发生的错误请求和错误率
错误是需要在添加监控时首要关注的指标。
在添加错误相关监控时，我们应该关注以下几个方面：
基础监控：宕机、磁盘（坏盘或文件系统错误）、进程或端口挂掉、网络丢包等故障
业务监控：
* 核心功能处理错误，每种系统都有特定的核心功能，比如HDFS的文件块读写、Zookeeper对Key的读写和修改操作
* 基础功能单元丢失或异常，这里的基础功能单元是指一个系统功能上的基本单位，例如HDFS的Block、Kafka的Message，这种基础数据的丢失一般都会对业务功能造成直接的影响
* Master故障，对于中心化的分布式系统来说，Master的健康状况都是重中之重。例如HDFS的NameNode、ZooKeeper的Leader，ElasticSearch的MasterNode
* 可用节点数，对于分布式系统来说，可用节点数也是非常重要的，比如ZooKeeper、ETCD等系统需要满足可用节点数大于不可用节点数才能保证功能的正常
注意：除白盒监控外，主要功能或接口、以及内部存在明显边界的功能模块和上游依赖模块，都应该添加黑盒端到端监控。
##延迟：服务请求所需时间
服务延迟的上升不仅仅体现在用户体验的下降，也有可能会导致请求堆积并最终演变为整个业务系统的雪崩。以下为延迟指标的主要关注点：
* 基础监控：IO等待、网络延迟
* 业务监控：业务相关指标主要需要关注核心功能的响应时长。比如ZooKeeper的延迟指标zk_avg_latency，ElasticSearch的索引、搜索延迟和慢查询
注意：与错误指标类似，白盒延迟指标通常仅能代表系统内部延迟，建议为主要功能或接口添加黑盒监控来采集端到端的延迟指标。
##流量：当前系统的流量
流量指标可以指系统层面的网络和磁盘IO，服务层面的QpS、PV和UV等数据。流量和突增或突减都可能预示着系统可能出现问题（攻击事件、系统故障……）。
* 基础监控：磁盘和网卡IO
* 业务监控：核心功能流量，例如通过QpS/PV/UV等通常能够代表Web服务的流量，而ElasticSearch的流量可用索引创建速率、搜索速率表示
##饱和度：用于衡量当前服务的利用率
更为通俗的讲，饱和度可以理解为服务的利用率，可以代表系统承受的压力。所以饱和度与流量息息相关，流量的上升一般也会导致饱和度的上升。通常情况下，每种业务系统都应该有各自的饱和度指标。在很多业务系统中，消息队列长度是一个比较重要的饱和度指标，除此之外CPU、内存、磁盘、网络等系统资源利用率也可以作为饱和度的一种体现方式。
基础监控：CPU、内存、磁盘和网络利用率、内存堆栈利用率、文件句柄数、TCP连接数等
业务监控：
* 基础功能单元使用率，大多数系统对其基础的功能单元都有其处理能力的上限，接近或达到该上限时可能会导致服务的错误、延迟增大。例如HDFS的Block数量上升会导致NameNode堆内存使用率上升，Kafka的Topics和Partitions的数量、Zookeeper的node数的上升都会对系统产生压力
* 消息队列长度，不少系统采用消息队列存放待处理数据，所以消息队列长度在一定程度上可以代表系统的繁忙程度。如ElasticSearch、HDFS等都有队列长度相关指标可供采集
#总结
以上总结了常见的监控指标采集方法，以及四个黄金指标所包含的常见内容。在实际工作中，不同的监控系统的设计多种多样，没有统一标准，并且不同的业务系统通常也有着特定的监控采集方法和不同的黄金指标定义，具体如何采集监控指标和添加告警都需要我们针对不同系统特点灵活应对。
原文链接：运维监控的终极秘籍，盘它！
本文将主要从白盒监控的采集入手，解答关于新系统如何添加监控的问题。
图 1 黑盒与白盒监控
#监控指标的采集
配置监控时，我们首要面对的是监控数据如何采集的问题。一般我们可以把监控指标分为两类：基础监控和业务监控。
##基础监控
包括CPU、内存、磁盘、端口和进程等机器、网络的操作系统级别的信息。通常情况下，成熟的监控系统（例如开源的Prometheus、Zabbix等）均会提供基础监控项的采集能力，这里不做过多介绍。但需要注意的一点，机器级别的基础监控指标一般并不能代表服务的真实运行状况，例如单台实例的故障对一个设计合理的分布式系统来说并不会带来严重后果。所以只有结合业务相关监控指标，基础监控指标才有意义。
##业务监控
业务监控指标由业务系统内部的服务产生，一般能够真实反应业务运行状态。设计合理的系统一般都会提供相关监控指标供监控系统采集。监控数据的采集方法一般可以分为以下几大类：
* 日志：日志可以包含服务运行的方方面面，是重要的监控数据来源。例如，通过Nginx access日志可以统计出错误（5xx）、延迟（响应时间）和流量，结合已知的容量上限就可以计算出饱和度。一般除监控系统提供的日志采集插件外，如Rsyslog、Logstash、Filebeat、Flume等都是比较优秀的日志采集软件
* JMX：多数Java开发的服务均可由JMX接口输出监控指标。不少监控系统也有集成JMX采集插件，除此之外我们也可通过jmxtrans、jmxcmd工具进行采集
* REST：提供REST API来进行监控数据的采集，如Hadoop、ElasticSearch
* OpenMetrics：得益于Prometheus的流行，作为Prometheus的监控数据采集方案，OpenMetrics可能很快会成为未来监控的业界标准。目前绝大部分热门开源服务均有官方或非官方的exporter可供使用
* 命令行：一些服务提供本地的命令来输出监控指标
* 主动上报：对于采用PUSH模型的监控系统来说，服务可以采取主动上报的方式把监控指标push到监控系统，如Java服务可使用Metrics接口自定义sink输出。另外，运维也可以使用自定义的监控插件来完成监控的采集
* 埋点：埋点是侵入式的监控数据采集方式，其优点是其可以更灵活地为我们提供业务内部的监控指标，当然缺点也很明显：需要在代码层面动手脚（常常需要研发支持，成本较高）
* 其它方式：以上未涵盖的监控指标采集方式，例如ZooKeeper的四字命令，MySQL的show status命令
以上列出了几种常见的监控指标采集方法，在实际工作，如果没有现成的监控采集插件，则需要我们自行开发采集脚本。
#四个黄金指标
图 2 四个黄金指标
无论业务系统如何复杂，监控指标如何眼花缭乱，但万变不离其宗，监控的目的无非是为了解服务运行状况、发现服务故障和帮助定位故障原因。为了达成这个目的，Google SRE总结的监控四个黄金指标对我们添加监控具有非常重要的指导意义。图 2给出四个黄金指标所包含的主要监控指标，下面我们就这四个黄金指标分别展开说明，并给出一些监控项的采集实例。
##错误：错误是指当前系统发生的错误请求和错误率
错误是需要在添加监控时首要关注的指标。
在添加错误相关监控时，我们应该关注以下几个方面：
基础监控：宕机、磁盘（坏盘或文件系统错误）、进程或端口挂掉、网络丢包等故障
业务监控：
* 核心功能处理错误，每种系统都有特定的核心功能，比如HDFS的文件块读写、Zookeeper对Key的读写和修改操作
* 基础功能单元丢失或异常，这里的基础功能单元是指一个系统功能上的基本单位，例如HDFS的Block、Kafka的Message，这种基础数据的丢失一般都会对业务功能造成直接的影响
* Master故障，对于中心化的分布式系统来说，Master的健康状况都是重中之重。例如HDFS的NameNode、ZooKeeper的Leader，ElasticSearch的MasterNode
* 可用节点数，对于分布式系统来说，可用节点数也是非常重要的，比如ZooKeeper、ETCD等系统需要满足可用节点数大于不可用节点数才能保证功能的正常
注意：除白盒监控外，主要功能或接口、以及内部存在明显边界的功能模块和上游依赖模块，都应该添加黑盒端到端监控。
##延迟：服务请求所需时间
服务延迟的上升不仅仅体现在用户体验的下降，也有可能会导致请求堆积并最终演变为整个业务系统的雪崩。以下为延迟指标的主要关注点：
* 基础监控：IO等待、网络延迟
* 业务监控：业务相关指标主要需要关注核心功能的响应时长。比如ZooKeeper的延迟指标zk_avg_latency，ElasticSearch的索引、搜索延迟和慢查询
注意：与错误指标类似，白盒延迟指标通常仅能代表系统内部延迟，建议为主要功能或接口添加黑盒监控来采集端到端的延迟指标。
##流量：当前系统的流量
流量指标可以指系统层面的网络和磁盘IO，服务层面的QpS、PV和UV等数据。流量和突增或突减都可能预示着系统可能出现问题（攻击事件、系统故障……）。
* 基础监控：磁盘和网卡IO
* 业务监控：核心功能流量，例如通过QpS/PV/UV等通常能够代表Web服务的流量，而ElasticSearch的流量可用索引创建速率、搜索速率表示
##饱和度：用于衡量当前服务的利用率
更为通俗的讲，饱和度可以理解为服务的利用率，可以代表系统承受的压力。所以饱和度与流量息息相关，流量的上升一般也会导致饱和度的上升。通常情况下，每种业务系统都应该有各自的饱和度指标。在很多业务系统中，消息队列长度是一个比较重要的饱和度指标，除此之外CPU、内存、磁盘、网络等系统资源利用率也可以作为饱和度的一种体现方式。
基础监控：CPU、内存、磁盘和网络利用率、内存堆栈利用率、文件句柄数、TCP连接数等
业务监控：
* 基础功能单元使用率，大多数系统对其基础的功能单元都有其处理能力的上限，接近或达到该上限时可能会导致服务的错误、延迟增大。例如HDFS的Block数量上升会导致NameNode堆内存使用率上升，Kafka的Topics和Partitions的数量、Zookeeper的node数的上升都会对系统产生压力
* 消息队列长度，不少系统采用消息队列存放待处理数据，所以消息队列长度在一定程度上可以代表系统的繁忙程度。如ElasticSearch、HDFS等都有队列长度相关指标可供采集
#总结
以上总结了常见的监控指标采集方法，以及四个黄金指标所包含的常见内容。在实际工作中，不同的监控系统的设计多种多样，没有统一标准，并且不同的业务系统通常也有着特定的监控采集方法和不同的黄金指标定义，具体如何采集监控指标和添加告警都需要我们针对不同系统特点灵活应对。
原文链接：运维监控的终极秘籍，盘它！
360互联网技术训练营第九期——360容器技术解密与实践 火热报名中！
HULK 发表了文章 • 0 个评论 • 894 次浏览 • 2018-04-03 10:56
随着服务端架构的飞速发展，传统的部署和维护方式已经不足以满足业务的飞速增长，容器做为目前最炙手可热的技术，为开发和运维人员带来了极大的便捷性。
在第九期360互联网技术训练营中，360的精英攻城狮们就来为大家讲解容器技术在360的应用与实践，看容 ...查看全部
随着服务端架构的飞速发展，传统的部署和维护方式已经不足以满足业务的飞速增长，容器做为目前最炙手可热的技术，为开发和运维人员带来了极大的便捷性。
在第九期360互联网技术训练营中，360的精英攻城狮们就来为大家讲解容器技术在360的应用与实践，看容器变利器，快速解决业务痛点。
同时更有hyper公司的技术大牛为我们带来相关的技术分享。
报名地址：http://www.huodongxing.com/event/2431945121700
现场还有小礼品哦！
在第九期360互联网技术训练营中，360的精英攻城狮们就来为大家讲解容器技术在360的应用与实践，看容器变利器，快速解决业务痛点。
同时更有hyper公司的技术大牛为我们带来相关的技术分享。
报名地址：http://www.huodongxing.com/event/2431945121700
现场还有小礼品哦！
怎样才是真正的灰度发布？
灵雀云 发表了文章 • 0 个评论 • 2342 次浏览 • 2018-01-31 11:23
究竟什么才是灰度发布其实并没有一个严格的标准，因为这个东西不是黑的也不是白的是个中间过渡地带，这类的东西定义都会比较麻烦。由于工作的原因看到好多友商所谓的灰度发布产品，有意思的是他们实现的是完全不一样的功能，对外都说自己是灰度发布。我看到的有三种： ...查看全部
究竟什么才是灰度发布其实并没有一个严格的标准，因为这个东西不是黑的也不是白的是个中间过渡地带，这类的东西定义都会比较麻烦。由于工作的原因看到好多友商所谓的灰度发布产品，有意思的是他们实现的是完全不一样的功能，对外都说自己是灰度发布。我看到的有三种：
1. 更新过程可以暂停，停在一个既有新版本又有旧版本的状态，然后选择升级或者回滚
2. 支持流量比例分配，可以把百分之几的流量分配给一个服务，剩下的给另一个服务
3. 支持 url 路径流量分配，一个路径下的流量给一个服务，另一个路径流量给另一个服务
那究竟哪个才能算是灰度发布呢？抛开具体的技术实现，让我们从需求的角度来考虑一下为什么要有灰度发布？灰度发布究竟是要做什么？从目的出发再来看技术实现就会清晰很多。
既然要灰度就是不希望所有人都看到，就是为了控制影响范围，之所以要做这种限制就说明发布的人心里对这个发布的版本就是不确定的，害怕影响范围太大风险不可控。也就是说这个风险因素在开发和测试环境都没有办法控制，只能在生产环境来观察，那究竟是怎样的因素会导致必须要上线观察而不是在开发测试环节来解决呢？主要有从运维和产品两大方面的考量因素。
从运维的角度讲，任何一次上线都是有风险的，或者有一些步骤的遗漏，流程的不规范，或者有一些隐藏的代码 bug都会导致线上的不稳定。控制风险的办法就是小批量上线，验证之后在全部更新。此外一些稳定性和性能的问题在开发测试环境很难复现，因此这一类的修复和功能只能到生产环境来验证，同样由于效果的未知也不可能全量更新。再有一些大的重构，比如编程语言的变化，框架的变化，基础库的更新，操作系统的更新都会有未知的影响，而这些影响也需要生产的检验。
从产品的角度讲，有一些产品设计，交互，界面展现形式都不是坐在办公室里拍桌子就可以定出最佳实践的。产品经理的视角和用户的视角是不同的，即使是产品经理之间的风格，偏好也是不一致的。小到按钮的顺序，弹框展示的位置，大到页面整体的布局，广告位的展示策略，究竟用哪种设计更好并没有理论上的最佳实践。而这种情况就需要大家分别作出自己的方案，去线上收集真实的用户数据作对比。也就是硅谷里常说的 A/B testing，也可以归到灰度发布的范畴。本质上就是基于数据驱动来作抉择，在用户的投票中选择哪种方案，而不是传统的看谁嗓门大会拍桌子，看谁官大来做决策。
了解了需求，我们就很容易推导出所有人都在说的灰度发布真正是什么了
1. 精确的流量分发控制
这是一切的核心，从运维风险控制的角度，需要把受影响的流量控制在一个精确的范围内，在上线前就知道哪部分用户会有问题，而不是真出问题谁受到影响都不知道。一个常见场景是新版本只让公司内部的员工能访问到，再一个市，一个省的一点点推上去。从产品角度看要做 A/B test，就需要控制测试样本，哪些用户是 A 版本，哪些用户是 B 版本，在发布后应该就是固定的，而不是一个用户一会儿访问 A，一会儿访问 B。而传统的负载均衡器策略只能做到粗犷的比例分配，并没有细粒度的流量规则控制。而一个理想的灰度发布系统应该有很细粒度的流量规则，比如匹配 android 用户，匹配某个地区的用户，甚至能组合多种条件匹配到特定的人群。
2. 监控系统的支撑
流量精确分配只是第一步，接下来更重要的是获得多个版本的关键指标。对运维来说可能是看错误率，吞吐量，延迟，cpu 内存消耗这些系统层面指标。对于产品来说可能是要看点击率，pv，uv 等业务指标的变化。这些都需要能把数据收集并作展示，来方便后续决策：全量推还是回滚？使用方案 A 还是 B？不然的话灰度发布带来不了更多业务方面的促进，也不能帮你更好的了解业务的状态和用户行为。
3. 灵活的发布系统
从上面的介绍可以看出灰度发布并不是个短暂的过程，可能会持续很久。例如某个重大的框架或者系统更新可能会持续很久，有可能整个服务在几个月内都是新旧并存，甚至有可能需要两个版本分别各自迭代。而从产品的角度来看可能就会更灵活，很有可能线上有五六个方案都在收集数据，每天有了一些新想法都要上一些小版本看效果，每个版本上线后可能都要再各自做优化调整观察效果。这种情况可能线上就永远不会有一个统一的版本灰度反而是个常态来应对不断变化的需求和挑战。而发布系统也需要做相应的调整，不在把每个服务看成一个单一版本的运行体，只在更新的短时间内出现多版本共存，只允许全量推和回滚这种粗粒度策略。而是应该将多版本共存看成常态，允许每个版本各自迭代，版本之间又能区分对应的监控日志信息，这样灵活的发布系统才能配合灵活的灰度策略。
说了这么写灰度系统要做的事情其实就是流量控制和数据收集，来控制风险并帮助产品做决策。再看一下最开始提出的三个所谓的灰度发布：更新过程可以暂停，流量比例分配，url分流。它们充其量也只是做到了流量精确分配的某几个特殊情况，而且还都是不很精确的分配。而如果结合使用场景就会发现，这几种在实际中是很难用起来的，因为没有流量的精确控制很难控制风险范围，如果风险都不可控，那还要灰度发布干什么呢？更不要提后面的监控数据收集和灵活的发布了。
所以说一个真实好用的发布系统是十分复杂的，绝对不是页面上点两三下就可以完成的，而后面的实现更需要一整套体系来支撑。如果你想打造一个灰度发布系统，希望这篇文章能对你有所启发。
自动化运维为什么是必须的？
goodrain 发表了文章 • 0 个评论 • 1653 次浏览 • 2017-08-31 12:37
运维团队负责最大限度提高效率、降低成本，这也意味着他们往往承受着巨大的压力，需要解决在不增加员工的情况下，最大限度产出价值的问题。
【烧脑式Kubernetes实战训练营】本次培训理论结合实践，主要包括：Kubernetes架构和资源 ...查看全部
运维团队负责最大限度提高效率、降低成本，这也意味着他们往往承受着巨大的压力，需要解决在不增加员工的情况下，最大限度产出价值的问题。
【烧脑式Kubernetes实战训练营】本次培训理论结合实践，主要包括：Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。
达成这样的要求，仅靠人工是很难的，采用自动化运维则是靠谱的选择。我们不妨总结一下自动化运维带来的好处——
消除无效率 - 运维工作的手动工作，如果可以实现自动化，将显著提升效率水平。
减少错误 - 即使最谨慎的人，也会犯错，尤其是面对着重复性工作。通过运维自动化工具来完成这样的工作，结果是显而易见的，错误率将大大降低。
最大化员工使用 - 通过运维自动化，运维专家们的经历可以集中在更复杂、更有战略意义的业务问题上。同时也降低了雇佣更多员工来应对工作量增加的需求。同样一批人，有自动化运维，就有更大的能量来创造价值。
提高满意度水平 - 自动化运维工具帮助IT运维，为内部和外部客户提供高水平支持。无论是通过提供自助服务选项，还是大幅缩短时间（最多达90％）来减少联系和等待服务台的需求，自动化运维让我们可以更好得拥抱SLA。
降低成本 - 系统中断、人为错误、重复工作，会导致不菲的费用和代价，而自动化运维几乎可以将这些成本完全消除。
为了获得最佳的结果，运维应该将自动化最为其“最佳实践”的一部分，尽可能多的实施自动化流程。除了成本和费用上的减少，无数例子证明，其业务敏捷性和整体服务提供也将呈指数级增长。
Source
```
好雨云帮ACP · 自动化运维
https://www.goodrain.com/autoOM.html
自动化运维把周期性、重复性、规律性的工作交给平台去处理，通过标准化、自动化、架构化、过程优化来降低运维成本、提高运维效率。云帮ACP提供从基础架构到应用的全栈自动化运维，安全、稳定、强大。
```
【烧脑式Kubernetes实战训练营】本次培训理论结合实践，主要包括：Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。
达成这样的要求，仅靠人工是很难的，采用自动化运维则是靠谱的选择。我们不妨总结一下自动化运维带来的好处——
消除无效率 - 运维工作的手动工作，如果可以实现自动化，将显著提升效率水平。
减少错误 - 即使最谨慎的人，也会犯错，尤其是面对着重复性工作。通过运维自动化工具来完成这样的工作，结果是显而易见的，错误率将大大降低。
最大化员工使用 - 通过运维自动化，运维专家们的经历可以集中在更复杂、更有战略意义的业务问题上。同时也降低了雇佣更多员工来应对工作量增加的需求。同样一批人，有自动化运维，就有更大的能量来创造价值。
提高满意度水平 - 自动化运维工具帮助IT运维，为内部和外部客户提供高水平支持。无论是通过提供自助服务选项，还是大幅缩短时间（最多达90％）来减少联系和等待服务台的需求，自动化运维让我们可以更好得拥抱SLA。
降低成本 - 系统中断、人为错误、重复工作，会导致不菲的费用和代价，而自动化运维几乎可以将这些成本完全消除。
为了获得最佳的结果，运维应该将自动化最为其“最佳实践”的一部分，尽可能多的实施自动化流程。除了成本和费用上的减少，无数例子证明，其业务敏捷性和整体服务提供也将呈指数级增长。
Source
```
好雨云帮ACP · 自动化运维
https://www.goodrain.com/autoOM.html
自动化运维把周期性、重复性、规律性的工作交给平台去处理，通过标准化、自动化、架构化、过程优化来降低运维成本、提高运维效率。云帮ACP提供从基础架构到应用的全栈自动化运维，安全、稳定、强大。
```
自动化运维要点
goodrain 发表了文章 • 0 个评论 • 2307 次浏览 • 2017-08-29 13:24
Source
什么是自动化运维
自动化运维是指将IT运维中日常的、大量的重复性工作自动化，把过去的手工执行转为自动化操作。自动化是IT运维工作的升华，自动化运维不单纯是一个维护过程，更是一个管理的提升过程， ...查看全部
Source
什么是自动化运维
自动化运维是指将IT运维中日常的、大量的重复性工作自动化，把过去的手工执行转为自动化操作。自动化是IT运维工作的升华，自动化运维不单纯是一个维护过程，更是一个管理的提升过程，是IT运维的最高层次，也是未来的发展趋势。
传统运维管理方式存在的问题
目前许多企业的IT运维已经实现从人工运维到计算机管理，但延展咨询在同客户的交流中发现其中很多企业的IT运维管理还只是处在「半自动化」的运维状态。因为这种IT运维仍然是等到IT故障出现后再由运维人员采取相应的补救措施。这些传统式被动、孤立、半自动式的IT运维管理模式经常让IT部门疲惫不堪，主要表现在以下三个方面:
* 运维人员被动、效率低
在IT运维过程中，只有当事件已经发生并已造成业务影响时才能发现和着手处理，这种被动「救火」不但使IT运维人员终日忙碌，也使IT运维本身质量很难提高，导致IT部门和业务部门对IT运维的服务满意度都不高。目前绝大多数的企业IT运维人员日常大部分时间和精力是处理一些简单重复的问题，而且由于故障预警机制不完善，往往是故障发生后或报警后才会进行处理，,使到IT运维人员的工作经常是处于被动「救火」的状态，不但事倍功半而且常常会出现恶性连锁反应。
* 缺乏一套高效的IT运维机制
目前许多企业在IT运维管理过程中缺少自动化的运维管理模式，也没有明确的角色定义和责任划分，使到问题出现后很难快速、准确地找到根本原因，无法及时地找到相应的人员进行修复和处理，或者是在问题找到后缺乏流程化的故障处理机制，而在处理问题时不但欠缺规范化的解决方案，也缺乏全面的跟踪记录。
* 缺乏高效的IT运维技术工具
随着信息化建设的深入，企业IT系统日趋复杂，林林总总的网路设备、伺服器、中间件、业务系统等让IT运维人员难以从容应对，即使加班加点地维护、部署、管理也经常会因设备出现故障而导致业务的中断，严重影响企业的正常运转。出现这些问题部分原因是企业缺乏事件监控和诊断工具等IT运维技术工具，因为在没有高效的技术工具的支持下故障事件很难得到主动、快速处理。
自动化运维迫在眉睫
尽管IT运维管理的技术在不断进步，但实际上很多IT运维人员并没有真正解脱出来，原因在于目前的技术虽然能够获取IT设备、伺服器、网路流量，甚至资料库的警告信息，但成千上万条警告信息堆积在一起更本没法判断问题的根源在哪里。另外，目前许多企业的更新管理绝大多数工作都是手工操作的。即使一个简单的系统变更或更新往往都需要运维人员逐一登录每台设备进行手工变更，当设备数量达至成百上千时，其工作量之大可想而知。而这样的变更和检查操作在IT运维中往往每天都在进行，占用了大量的运维资源。因此，实现运维管理工作的自动化对企业来说已迫在眉睫。
现在随着IT运维管理工作的复杂度和难度的大大增加，仅靠过去几个「运维英雄」或「技术大拿」来包打天下已经行不通了，企业开始需要运用专业化、标准化和流程化的手段来实现运维工作的自动化管理。因为通过自动化监控系统能及时发现故障隐患，主动的告诉用户需要关注的资源，以达到防患于未然。例如，全天候自动检测与及时报警能实现IT运维的「全天候无人值守」，大大降低IT运维人员的工作负担。而且，通过自动化诊断能最大限度地减少维修时间,提高服务质量。因此, 对于越来越复杂的IT运维来说，将纯粹的人工操作变为一定程度的自动化管理是一个重要发展趋势。
首先，IT运维流程自动化能够提高流程的可控性，可以基于业务需求来制定个性化的流程，使企业领导有机会看见他们的业务流程，对企业流程有一个深刻的分析和理解，进而改造和优化流程。
其次，IT运维流程的自动化能提高透明度。因为随着业务需求的变化可能会有多个版本出现，手工流程的不透明将会给流程定制和优化带来相当大的困难，而自动化流程可以使用户能够一目了然的看到整个流程的各个节点运转情况，自动化工具潜移默化地提升业务保障能力。
再者，运维系统实行了自动化监控以后，通过工具自动监控对人的工作是一种减负，也是一种降低成本的表现。
自动化运维管理的具体内容
IT运维已经在风风雨雨中走过了十几个春秋，如今它正以一种全新的姿态摆在我们面前--自动化，这是IT技术发展的必然结果。现在IT系统的复杂性已经客观上要求IT运维必须能够实现数字化、自动化维护。所谓IT运维管理的自动化是指通过将日常IT运维中大量的重复性工作（小到简单的日常检查、配置变更和软体安装，大到整个变更流程的组织调度）由过去的手工执行转为自动化操作，从而减少乃至消除运维中的延迟，实现「零延时」的IT运维。
简单的说，自动化运维是指基于流程化的框架，将事件与IT流程相关联，一旦被监控系统发生性能超标或宕机，会触发相关事件以及事先定义好的流程，可自动启动故障响应和恢复机制。自动化工作平台还可帮助IT运维人员完成日常的重复性工作(如备份、杀毒等)，提高IT运维效率。同时，IT运维的自动化还要求能够预测故障、在故障发生前能够报警，让IT运维人员把故障消除在发生前，将所产生损失减到最低。
自动化运维的工具
对于企业来说，要特别关注两类自动化工具：一是IT运维监控和诊断优化工具；二是运维流程自动化工具。这两类工具主要应用于：
* 监控自动化，是指对重要的IT设备实施主动式监控,如路由器、交换机、防火墙等；
* 配置变更检测自动化，是指IT设备配置参数一旦发生变化，将触发变更流程转给相关技术人员进行确认,通过自动检测协助IT运维人员发现和维护配置。
* 维护事件提醒自动化,是指通过对IT设备和应用活动的时时监控,当发生异常事件时系统自动启动报警和响应机制,第一事件通知相关责任人。
* 系统健康检测自动化,是指定期自动地对IT设备硬体和应用系统进行健康巡检,配合IT运维团队实施对系统的健康检查和监控。
* 维护报告生成自动化,是指定期自动的对系统做日志的收集分析,记录系统运行状况,并通过阶段性的监控、分析和总结,定时提供IT运维的可用性、性能、系统资源利用状况分析报告。
```
好雨云帮ACP · 自动化运维
https://www.goodrain.com/autoOM.html
自动化运维把周期性、重复性、规律性的工作交给平台去处理，通过标准化、自动化、架构化、过程优化来降低运维成本、提高运维效率。云帮ACP提供从基础架构到应用的全栈自动化运维，安全、稳定、强大。
```
建立高效自动化运维管理的步骤
* 建立自动化运维管理平台
自动化运维管理建设的第一步是要先建立IT运维的自动化监控和管理平台。通过监控工具实现对用户操作规范的约束和对IT资源进行实时监控，包括伺服器、资料库、中间件、存储备份、网路、安全、机房、业务应用和客户端等内容，通过自动监控管理平台实现故障或问题综合处理和集中管理。例如，在自定义周期内进行自动触发完成对IT运维的例行巡检，形成检查报告。包括自动运行维护，以完成对系统补丁的同步分发与升级、数据备份、病毒查杀等工作。
* 建立故障事件自动触发流程，提高故障处理效率
所有IT设备在遇到问题时要会自动报警，无论是系统自动报警还是使用人员报的故障，应以红色标识显示在运维屏幕上。然后IT运维人员只需要按照相关知识库的数据，一步一步操作就可以。因此，企业需要事先建立自动工单式流程管理，当设备或软体发生异常或超出预警指标时会触发相关的事件，同时触发相关工单处理流程给相关IT运维人员。 IT运维人员必须在指定时间内完成流程所规定的环节与工作，以提高IT运维响应问题的效率。
* 建立规范的事件跟踪流程，强化运维执行力度
自动化运维管理建设时，首先需要建立故障和事件处理跟踪流程，利用表格工具等记录故障及其处理情况，以建立运维日志，并定期回顾从中辨识和发现问题的线索和根源。事实上许多实践也证明，建立每种事件的规范化处理和跟踪指南，可以减少IT运维操作的随意性和强化运维的执行力度，在很大程度上可降低故障发生的概率。同时，用户还应可以通过自助服务台、电话服务台等随时追踪该故障请求的处理状态。
* 设立IT运维关键流程，引入优先处理原则
设立IT运维关键流程，引入优先处理原则是指要求CIO定义出IT运维的每个关键流程，不仅仅是定义流程是什么，还包括要指出每个关键流程对企业有什么影响和意义。同时，在设置自动化流程时还需要引入优先处理原则，例行的事按常规处理，特别事件要按优先顺序次序处理，也就是把事件细分为例行事件和例外关键事件。
总之，实现IT运维的自动化管理是指通过将IT运维中日常的、大量的重复性工作自动化，把过去的手工执行转为自动化操作。自动化是IT运维工作的升华，自动化运维不单纯是一个维护过程，更是一个管理的提升过程，是IT运维的最高层次，也是未来的发展趋势。
什么是自动化运维
自动化运维是指将IT运维中日常的、大量的重复性工作自动化，把过去的手工执行转为自动化操作。自动化是IT运维工作的升华，自动化运维不单纯是一个维护过程，更是一个管理的提升过程，是IT运维的最高层次，也是未来的发展趋势。
传统运维管理方式存在的问题
目前许多企业的IT运维已经实现从人工运维到计算机管理，但延展咨询在同客户的交流中发现其中很多企业的IT运维管理还只是处在「半自动化」的运维状态。因为这种IT运维仍然是等到IT故障出现后再由运维人员采取相应的补救措施。这些传统式被动、孤立、半自动式的IT运维管理模式经常让IT部门疲惫不堪，主要表现在以下三个方面:
* 运维人员被动、效率低
在IT运维过程中，只有当事件已经发生并已造成业务影响时才能发现和着手处理，这种被动「救火」不但使IT运维人员终日忙碌，也使IT运维本身质量很难提高，导致IT部门和业务部门对IT运维的服务满意度都不高。目前绝大多数的企业IT运维人员日常大部分时间和精力是处理一些简单重复的问题，而且由于故障预警机制不完善，往往是故障发生后或报警后才会进行处理，,使到IT运维人员的工作经常是处于被动「救火」的状态，不但事倍功半而且常常会出现恶性连锁反应。
* 缺乏一套高效的IT运维机制
目前许多企业在IT运维管理过程中缺少自动化的运维管理模式，也没有明确的角色定义和责任划分，使到问题出现后很难快速、准确地找到根本原因，无法及时地找到相应的人员进行修复和处理，或者是在问题找到后缺乏流程化的故障处理机制，而在处理问题时不但欠缺规范化的解决方案，也缺乏全面的跟踪记录。
* 缺乏高效的IT运维技术工具
随着信息化建设的深入，企业IT系统日趋复杂，林林总总的网路设备、伺服器、中间件、业务系统等让IT运维人员难以从容应对，即使加班加点地维护、部署、管理也经常会因设备出现故障而导致业务的中断，严重影响企业的正常运转。出现这些问题部分原因是企业缺乏事件监控和诊断工具等IT运维技术工具，因为在没有高效的技术工具的支持下故障事件很难得到主动、快速处理。
自动化运维迫在眉睫
尽管IT运维管理的技术在不断进步，但实际上很多IT运维人员并没有真正解脱出来，原因在于目前的技术虽然能够获取IT设备、伺服器、网路流量，甚至资料库的警告信息，但成千上万条警告信息堆积在一起更本没法判断问题的根源在哪里。另外，目前许多企业的更新管理绝大多数工作都是手工操作的。即使一个简单的系统变更或更新往往都需要运维人员逐一登录每台设备进行手工变更，当设备数量达至成百上千时，其工作量之大可想而知。而这样的变更和检查操作在IT运维中往往每天都在进行，占用了大量的运维资源。因此，实现运维管理工作的自动化对企业来说已迫在眉睫。
现在随着IT运维管理工作的复杂度和难度的大大增加，仅靠过去几个「运维英雄」或「技术大拿」来包打天下已经行不通了，企业开始需要运用专业化、标准化和流程化的手段来实现运维工作的自动化管理。因为通过自动化监控系统能及时发现故障隐患，主动的告诉用户需要关注的资源，以达到防患于未然。例如，全天候自动检测与及时报警能实现IT运维的「全天候无人值守」，大大降低IT运维人员的工作负担。而且，通过自动化诊断能最大限度地减少维修时间,提高服务质量。因此, 对于越来越复杂的IT运维来说，将纯粹的人工操作变为一定程度的自动化管理是一个重要发展趋势。
首先，IT运维流程自动化能够提高流程的可控性，可以基于业务需求来制定个性化的流程，使企业领导有机会看见他们的业务流程，对企业流程有一个深刻的分析和理解，进而改造和优化流程。
其次，IT运维流程的自动化能提高透明度。因为随着业务需求的变化可能会有多个版本出现，手工流程的不透明将会给流程定制和优化带来相当大的困难，而自动化流程可以使用户能够一目了然的看到整个流程的各个节点运转情况，自动化工具潜移默化地提升业务保障能力。
再者，运维系统实行了自动化监控以后，通过工具自动监控对人的工作是一种减负，也是一种降低成本的表现。
自动化运维管理的具体内容
IT运维已经在风风雨雨中走过了十几个春秋，如今它正以一种全新的姿态摆在我们面前--自动化，这是IT技术发展的必然结果。现在IT系统的复杂性已经客观上要求IT运维必须能够实现数字化、自动化维护。所谓IT运维管理的自动化是指通过将日常IT运维中大量的重复性工作（小到简单的日常检查、配置变更和软体安装，大到整个变更流程的组织调度）由过去的手工执行转为自动化操作，从而减少乃至消除运维中的延迟，实现「零延时」的IT运维。
简单的说，自动化运维是指基于流程化的框架，将事件与IT流程相关联，一旦被监控系统发生性能超标或宕机，会触发相关事件以及事先定义好的流程，可自动启动故障响应和恢复机制。自动化工作平台还可帮助IT运维人员完成日常的重复性工作(如备份、杀毒等)，提高IT运维效率。同时，IT运维的自动化还要求能够预测故障、在故障发生前能够报警，让IT运维人员把故障消除在发生前，将所产生损失减到最低。
自动化运维的工具
对于企业来说，要特别关注两类自动化工具：一是IT运维监控和诊断优化工具；二是运维流程自动化工具。这两类工具主要应用于：
* 监控自动化，是指对重要的IT设备实施主动式监控,如路由器、交换机、防火墙等；
* 配置变更检测自动化，是指IT设备配置参数一旦发生变化，将触发变更流程转给相关技术人员进行确认,通过自动检测协助IT运维人员发现和维护配置。
* 维护事件提醒自动化,是指通过对IT设备和应用活动的时时监控,当发生异常事件时系统自动启动报警和响应机制,第一事件通知相关责任人。
* 系统健康检测自动化,是指定期自动地对IT设备硬体和应用系统进行健康巡检,配合IT运维团队实施对系统的健康检查和监控。
* 维护报告生成自动化,是指定期自动的对系统做日志的收集分析,记录系统运行状况,并通过阶段性的监控、分析和总结,定时提供IT运维的可用性、性能、系统资源利用状况分析报告。
```
好雨云帮ACP · 自动化运维
https://www.goodrain.com/autoOM.html
自动化运维把周期性、重复性、规律性的工作交给平台去处理，通过标准化、自动化、架构化、过程优化来降低运维成本、提高运维效率。云帮ACP提供从基础架构到应用的全栈自动化运维，安全、稳定、强大。
```
建立高效自动化运维管理的步骤
* 建立自动化运维管理平台
自动化运维管理建设的第一步是要先建立IT运维的自动化监控和管理平台。通过监控工具实现对用户操作规范的约束和对IT资源进行实时监控，包括伺服器、资料库、中间件、存储备份、网路、安全、机房、业务应用和客户端等内容，通过自动监控管理平台实现故障或问题综合处理和集中管理。例如，在自定义周期内进行自动触发完成对IT运维的例行巡检，形成检查报告。包括自动运行维护，以完成对系统补丁的同步分发与升级、数据备份、病毒查杀等工作。
* 建立故障事件自动触发流程，提高故障处理效率
所有IT设备在遇到问题时要会自动报警，无论是系统自动报警还是使用人员报的故障，应以红色标识显示在运维屏幕上。然后IT运维人员只需要按照相关知识库的数据，一步一步操作就可以。因此，企业需要事先建立自动工单式流程管理，当设备或软体发生异常或超出预警指标时会触发相关的事件，同时触发相关工单处理流程给相关IT运维人员。 IT运维人员必须在指定时间内完成流程所规定的环节与工作，以提高IT运维响应问题的效率。
* 建立规范的事件跟踪流程，强化运维执行力度
自动化运维管理建设时，首先需要建立故障和事件处理跟踪流程，利用表格工具等记录故障及其处理情况，以建立运维日志，并定期回顾从中辨识和发现问题的线索和根源。事实上许多实践也证明，建立每种事件的规范化处理和跟踪指南，可以减少IT运维操作的随意性和强化运维的执行力度，在很大程度上可降低故障发生的概率。同时，用户还应可以通过自助服务台、电话服务台等随时追踪该故障请求的处理状态。
* 设立IT运维关键流程，引入优先处理原则
设立IT运维关键流程，引入优先处理原则是指要求CIO定义出IT运维的每个关键流程，不仅仅是定义流程是什么，还包括要指出每个关键流程对企业有什么影响和意义。同时，在设置自动化流程时还需要引入优先处理原则，例行的事按常规处理，特别事件要按优先顺序次序处理，也就是把事件细分为例行事件和例外关键事件。
总之，实现IT运维的自动化管理是指通过将IT运维中日常的、大量的重复性工作自动化，把过去的手工执行转为自动化操作。自动化是IT运维工作的升华，自动化运维不单纯是一个维护过程，更是一个管理的提升过程，是IT运维的最高层次，也是未来的发展趋势。
2017 OpenStack峰会：k8S抢尽风头？
精灵云 发表了文章 • 0 个评论 • 1740 次浏览 • 2017-05-11 15:43
编者按：2017年OpenStack峰会（5.8-5.11）正在如火如荼进行， OpenStack和K8s的“相爱相杀”正在陆续上演，K8s可谓抢尽本届峰会的风头，成了不折不扣的主角。虽然大多数美国分析师都认为可以通过大会讨论出未来方向和结果，但笔者认为真正的 ...查看全部
编者按：2017年OpenStack峰会（5.8-5.11）正在如火如荼进行， OpenStack和K8s的“相爱相杀”正在陆续上演，K8s可谓抢尽本届峰会的风头，成了不折不扣的主角。虽然大多数美国分析师都认为可以通过大会讨论出未来方向和结果，但笔者认为真正的结果在企业用户心中。只有实际成功的案例才能真正说明二者微妙的关系，正所谓“黑猫白猫，能抓到老鼠的猫才是好猫”。
2017 OpenStack Summit大会正在如火如荼的进行，在会议开始之前，这三行问题就已引人关注：
**“OpenStack on Kubernetes？
Kubernetes on OpenStack？
How about Kubernetes on OpenStack on Kubernetes？”**
以下是分组会议的话题清单，我们似乎可以从中看出些什么：
Kubernetes和大规模OpenStack；
企业采用Kubernetes和容器；
OpenDaylight Kubernetes和OpenStack Magnum集成；
ESCaaS 4.0，OpenStack和Kubernetes的统一管理平台；
混合云Kubernetes。
没错，一个非常明确的重点：Kubernetes。
2017年，OpenStack在全球范围内的企业数据中心正获得越来越多的部署。OpenStack最初的存在是为了让私有云基础设施能够像公共云一样方便快捷地支持应用程序。回顾OpenStack这些年所遇到的需求和面临的挑战，似乎都通过使用Kubernetes得以解决。
相关组织做了一次问卷调查，调查数字表明，使用OpenStack的受访者中，84%的人很高兴讨论他们在什么行业，他们负责什么方面的工作，但很多人不热衷于回答问卷中最重要的一个问题：“你用什么容器或PaaS平台工具来管理你的应用程序？”
在少数回答了这个问题的人中，大约43％的人表示他们使用Kubernetes来管理他们的应用程序，而其他选项（包括Swarm和Mesos）都低于该数字。
为什么？
峰会这几天，所有人都在围绕这三大问题展开讨论:
1、Kubernetes真的能成为OpenStack的实际应用程序服务管理组件？
如果这个问题换成“OpenStack和Kubernetes在私有云部署中分别扮演什么角色？”那就可以简单地回答说，“OpenStack管理基础设施，Kubernetes管理容器，”
OpenStack的文档指出：Magnum是一个OpenStack项目，它提供容器编排引擎来进行部署和管理。将Magnum与Kubernetes、Swarm或Mesos集成在一起，是一个非常好的思路。
认真的工程师必须提出这个问题：怎样的整合才是最可取的？
2、OpenStack名声大噪，却难以部署和管理吗？
据悉，OpenStack基金会在其4月调查报告中承认，用户的反馈集中在安装方面缺乏一致性，缺乏共同的生命周期管理工具，缺乏自动化部署系统，缺乏标准化升级过程，缺乏对BUG修复的关注，以及几乎所有工作流程中都有难以估量的步骤数量，这些都是OpenStack用户们强烈反馈的问题。
3、谁是OpenStack的领导者和推动者？
几年前，分析师们认为OpenStack重要性是显而易见的，否则惠普就不会投入如此多的资金来推动它。后来，当惠普退出时，一些分析师又宣布OpenStack将走向死亡。
但是很少有人注意到：获得惠普OpenStack业务的SUSE Linux可能更适合惠普向他的客户们提供这些服务。
大多数市场感知中存在着现实，在分析师眼中，该平台的方向即将明确，但对于大多数客户来说，由供应商和小团队供应商提供的案例才最具吸引力。
峰会热切进行中，OpenStack仍然是软件历史上最前所未有的集体努力者之一，相比之下，部分Linux的成功可能才是偶然的。
2017 OpenStack Summit大会正在如火如荼的进行，在会议开始之前，这三行问题就已引人关注：
**“OpenStack on Kubernetes？
Kubernetes on OpenStack？
How about Kubernetes on OpenStack on Kubernetes？”**
以下是分组会议的话题清单，我们似乎可以从中看出些什么：
Kubernetes和大规模OpenStack；
企业采用Kubernetes和容器；
OpenDaylight Kubernetes和OpenStack Magnum集成；
ESCaaS 4.0，OpenStack和Kubernetes的统一管理平台；
混合云Kubernetes。
没错，一个非常明确的重点：Kubernetes。
2017年，OpenStack在全球范围内的企业数据中心正获得越来越多的部署。OpenStack最初的存在是为了让私有云基础设施能够像公共云一样方便快捷地支持应用程序。回顾OpenStack这些年所遇到的需求和面临的挑战，似乎都通过使用Kubernetes得以解决。
相关组织做了一次问卷调查，调查数字表明，使用OpenStack的受访者中，84%的人很高兴讨论他们在什么行业，他们负责什么方面的工作，但很多人不热衷于回答问卷中最重要的一个问题：“你用什么容器或PaaS平台工具来管理你的应用程序？”
在少数回答了这个问题的人中，大约43％的人表示他们使用Kubernetes来管理他们的应用程序，而其他选项（包括Swarm和Mesos）都低于该数字。
为什么？
峰会这几天，所有人都在围绕这三大问题展开讨论:
1、Kubernetes真的能成为OpenStack的实际应用程序服务管理组件？
如果这个问题换成“OpenStack和Kubernetes在私有云部署中分别扮演什么角色？”那就可以简单地回答说，“OpenStack管理基础设施，Kubernetes管理容器，”
OpenStack的文档指出：Magnum是一个OpenStack项目，它提供容器编排引擎来进行部署和管理。将Magnum与Kubernetes、Swarm或Mesos集成在一起，是一个非常好的思路。
认真的工程师必须提出这个问题：怎样的整合才是最可取的？
2、OpenStack名声大噪，却难以部署和管理吗？
据悉，OpenStack基金会在其4月调查报告中承认，用户的反馈集中在安装方面缺乏一致性，缺乏共同的生命周期管理工具，缺乏自动化部署系统，缺乏标准化升级过程，缺乏对BUG修复的关注，以及几乎所有工作流程中都有难以估量的步骤数量，这些都是OpenStack用户们强烈反馈的问题。
3、谁是OpenStack的领导者和推动者？
几年前，分析师们认为OpenStack重要性是显而易见的，否则惠普就不会投入如此多的资金来推动它。后来，当惠普退出时，一些分析师又宣布OpenStack将走向死亡。
但是很少有人注意到：获得惠普OpenStack业务的SUSE Linux可能更适合惠普向他的客户们提供这些服务。
大多数市场感知中存在着现实，在分析师眼中，该平台的方向即将明确，但对于大多数客户来说，由供应商和小团队供应商提供的案例才最具吸引力。
峰会热切进行中，OpenStack仍然是软件历史上最前所未有的集体努力者之一，相比之下，部分Linux的成功可能才是偶然的。
那些影响传统PaaS平台结构的容器编排工具
精灵云 发表了文章 • 2 个评论 • 2203 次浏览 • 2017-05-09 17:25
作者：精灵云
随着PaaS平台结构的演变，可以看到容器编排给企业在平台结构的选择上带来的冲击，可究竟该如何选择，我们需要透过现象看本质。
PaaS平台的演变
传统PaaS平台在云计算技术的发展中经历了几次演变， ...查看全部
作者：精灵云
随着PaaS平台结构的演变，可以看到容器编排给企业在平台结构的选择上带来的冲击，可究竟该如何选择，我们需要透过现象看本质。
PaaS平台的演变
传统PaaS平台在云计算技术的发展中经历了几次演变，我们先来回顾下经典的云平台层次体系的结构。
传统云计算平台的分层结构
如图所示，在经典的PaaS平台结构中，应用运行在PaaS平台所提供的容器环境中，容器在虚拟机基础上完成了第二层次基础设施资源的划分，容器封装了应用正常运行所需的运行环境和系统。然而这类PaaS平台就如同一个“黑盒”，应用完全脱离了租户的控制，进入了完全被托管的状态，这使得开发人员和运维人员对应用和应用运行时的环境掌控力变弱，再加上传统PaaS通常在应用架构选择、支持的环境服务等方面有较强限制，导致此类云平台层次结构运力不足，尤其是在应用出现宕机后尤为凸显。因而在生产环境下又进化出了以IaaS+云平台的分层结构。
典型的IaaS+云平台
IaaS+云平台的层次结构保证了运维人员对底层环境的掌控，但IaaS层不具备贴近应用的资源调度策略，为了弥补了IaaS平台脱离应用的缺陷，出现了很多高效便捷的虚拟机DevOps工具，以虚拟机镜像为基础可以保证生产环境、测试环境、开发环境上的严格一致。目前基于IaaS的云生态环境已经具有相当高的成熟度。
当然，以上这两种经典的云平台分层结构依然还是目前传统云平台搭建意识里的主流，直到Docker的出现。
基于容器的云平台
Docker的出现为云平台带来了一个新的分层结构：基于容器的云平台。相比经典PaaS平台，基于容器的云平台结构更加开放，可直接基于虚拟机或物理机搭建。基于容器镜像的应用发布流程不仅能覆盖整个应用生命周期，还减少了经典PaaS平台对应用架构、支持的软件环境服务等方面的诸多限制，将更多控制力交还给开发和运维人员。
而影响传统平台PaaS结构的核心便是容器编排。
容器编排的演变
容器编排支持打包、部署、隔离、服务发现、扩容和滚动更新，已经在影响驱动成熟企业和初创公司采用容器上起到非常重要作用。
在基于容器的云平台中，运用Docker容器至应用的完整生命周期中时，最困难的便是运行微服务应用程序，即如何创建、管理和自动化临时容器集群。
解决这一挑战的第一个主要工具是Mesos及它的编排工具Marathon，成熟度最高时间最久。下一个得到认同的编排工具是Kubernetes（以下简称K8s），应用最广泛，社区支持度最高。之后Docker Swarm也加入了进来，使用覆盖率也很惊喜。当然，目前国内还出现了自研的容器编排Newben，开发者为Ghostcloud精灵云。
几种容器编排的对比
事实上，如今K8s因为它的可扩展性已经成为了企业主流。它支持广泛的编程语言、基础设施选项，并获得容器生态系统的巨大支持。它将应用层与基础设施层隔离开来，从而能够跨多个云供应商和基础设施设置，实现真正的可移植性。
容器编排K8s和Newben
本文重点介绍在网络、应用迁移、应用快照、模板、负载均衡、弹性伸缩、高可用、CI/CD集成、灰度发布和回滚、镜像集成、日志监控等方面同样优秀的两类容器编排工具Newben和K8s。Newben是Ghostcloud精灵云全自主研发的容器调度引擎，是目前国内唯一自研引擎。（关于Newben的介绍可阅读文章《全自主研发容器调度引擎——Newben》）K8s是目前最主流的容器编排。在此，我们简略地列出了Newben和K8s的部分功能特性，来展示这两种容器调度引擎在网络、应用迁移、负载均衡、弹性伸缩、调度规则等方面的优势。
网络
K8s不支持内置虚拟网络，网络插件选择众多，学习成本更高，但从社区获得的支持也最多。Newben内置支持虚拟网络，支持多子网，支持公有云、主机托管环境、二层和三层网络以及控制网络访问安全。
应用服务和应用栈
在创建应用服务方面， K8s需要多次执行命令工具的操作模式，Newben则采用向导式创建的方式，且支持应用服务分组创建应用栈。
弹性伸缩
Newben和K8s均可以支持CPU的弹性伸缩。
负载均衡
Newben和K8s均可实现负载均衡和高可用集群。
调度规则
K8s的调度规则基于标签选择器，而Newben则同时基于标签选择和指定主机名。
结语
对企业而言，编排工具是容器应用成功的关键，最主流的PaaS解决方案已经拥抱容器，并有新的PaaS 建立在容器编排之上实现管理平台。企业可以选择面向IT运维，部署核心容器编排工具，或面向开发，使用PaaS平台。
推荐阅读：
企业为什么要使用基于Docker的PaaS/CaaS平台
Docker容器云在金融行业的应用
自研容器调度引擎Newben会成为“中国的K8s”？
随着PaaS平台结构的演变，可以看到容器编排给企业在平台结构的选择上带来的冲击，可究竟该如何选择，我们需要透过现象看本质。
PaaS平台的演变
传统PaaS平台在云计算技术的发展中经历了几次演变，我们先来回顾下经典的云平台层次体系的结构。
传统云计算平台的分层结构
如图所示，在经典的PaaS平台结构中，应用运行在PaaS平台所提供的容器环境中，容器在虚拟机基础上完成了第二层次基础设施资源的划分，容器封装了应用正常运行所需的运行环境和系统。然而这类PaaS平台就如同一个“黑盒”，应用完全脱离了租户的控制，进入了完全被托管的状态，这使得开发人员和运维人员对应用和应用运行时的环境掌控力变弱，再加上传统PaaS通常在应用架构选择、支持的环境服务等方面有较强限制，导致此类云平台层次结构运力不足，尤其是在应用出现宕机后尤为凸显。因而在生产环境下又进化出了以IaaS+云平台的分层结构。
典型的IaaS+云平台
IaaS+云平台的层次结构保证了运维人员对底层环境的掌控，但IaaS层不具备贴近应用的资源调度策略，为了弥补了IaaS平台脱离应用的缺陷，出现了很多高效便捷的虚拟机DevOps工具，以虚拟机镜像为基础可以保证生产环境、测试环境、开发环境上的严格一致。目前基于IaaS的云生态环境已经具有相当高的成熟度。
当然，以上这两种经典的云平台分层结构依然还是目前传统云平台搭建意识里的主流，直到Docker的出现。
基于容器的云平台
Docker的出现为云平台带来了一个新的分层结构：基于容器的云平台。相比经典PaaS平台，基于容器的云平台结构更加开放，可直接基于虚拟机或物理机搭建。基于容器镜像的应用发布流程不仅能覆盖整个应用生命周期，还减少了经典PaaS平台对应用架构、支持的软件环境服务等方面的诸多限制，将更多控制力交还给开发和运维人员。
而影响传统平台PaaS结构的核心便是容器编排。
容器编排的演变
容器编排支持打包、部署、隔离、服务发现、扩容和滚动更新，已经在影响驱动成熟企业和初创公司采用容器上起到非常重要作用。
在基于容器的云平台中，运用Docker容器至应用的完整生命周期中时，最困难的便是运行微服务应用程序，即如何创建、管理和自动化临时容器集群。
解决这一挑战的第一个主要工具是Mesos及它的编排工具Marathon，成熟度最高时间最久。下一个得到认同的编排工具是Kubernetes（以下简称K8s），应用最广泛，社区支持度最高。之后Docker Swarm也加入了进来，使用覆盖率也很惊喜。当然，目前国内还出现了自研的容器编排Newben，开发者为Ghostcloud精灵云。
几种容器编排的对比
事实上，如今K8s因为它的可扩展性已经成为了企业主流。它支持广泛的编程语言、基础设施选项，并获得容器生态系统的巨大支持。它将应用层与基础设施层隔离开来，从而能够跨多个云供应商和基础设施设置，实现真正的可移植性。
容器编排K8s和Newben
本文重点介绍在网络、应用迁移、应用快照、模板、负载均衡、弹性伸缩、高可用、CI/CD集成、灰度发布和回滚、镜像集成、日志监控等方面同样优秀的两类容器编排工具Newben和K8s。Newben是Ghostcloud精灵云全自主研发的容器调度引擎，是目前国内唯一自研引擎。（关于Newben的介绍可阅读文章《全自主研发容器调度引擎——Newben》）K8s是目前最主流的容器编排。在此，我们简略地列出了Newben和K8s的部分功能特性，来展示这两种容器调度引擎在网络、应用迁移、负载均衡、弹性伸缩、调度规则等方面的优势。
网络
K8s不支持内置虚拟网络，网络插件选择众多，学习成本更高，但从社区获得的支持也最多。Newben内置支持虚拟网络，支持多子网，支持公有云、主机托管环境、二层和三层网络以及控制网络访问安全。
应用服务和应用栈
在创建应用服务方面， K8s需要多次执行命令工具的操作模式，Newben则采用向导式创建的方式，且支持应用服务分组创建应用栈。
弹性伸缩
Newben和K8s均可以支持CPU的弹性伸缩。
负载均衡
Newben和K8s均可实现负载均衡和高可用集群。
调度规则
K8s的调度规则基于标签选择器，而Newben则同时基于标签选择和指定主机名。
结语
对企业而言，编排工具是容器应用成功的关键，最主流的PaaS解决方案已经拥抱容器，并有新的PaaS 建立在容器编排之上实现管理平台。企业可以选择面向IT运维，部署核心容器编排工具，或面向开发，使用PaaS平台。
推荐阅读：
企业为什么要使用基于Docker的PaaS/CaaS平台
Docker容器云在金融行业的应用
自研容器调度引擎Newben会成为“中国的K8s”？
