运维思索

如果我们的生产服务器没有做到开发、运维、测试人员的权限分离，那么本次的高危命令总结就可以派上用场了。

数据无处不在，数据风险也就如影随形，因此运维要对数据有敬畏之心，这和运维经验是否丰富无关。要想做到数据的安全性，我们需要一直保持警惕性。

云原生的理念经过几年发展，不断丰富、落地、实践，云原生已经渡过了概念普及阶段，进入了快速发展期。而无论我们所在的企业是否已经开启了云原生建设，我们都需要去充分的认识云原生，不断的储备和云原生相关

一套基于 NetFLOW / sFLOW 的流量统计报告系统流量统计报告系统和Python + Celery 实践。

Pipelin支撑起了各个动作的具体实现，各条Pipeline还可以被其他Pipeline调用，非常的灵活。

需求 运维是事件驱动，还是自驱动可能是我们在运维工作中不太关注的问题。事件驱动让运维止步于故障，而自驱动让运维不止于建设。持续性的运维建设就需要一套自动化的运维体系，那么我们应该从何入手？ 其实前期《

总结出一份用于运维过程中各个环境的JVM参数其实很简单，关键在于我们是否意识到了一份进程管理规范的重要性，怎样和当前的自动化水平来结合，实现其最终的价值。

经过长时间的流量分析、攻防实战，通过自建的WAF我们防住了大部分的恶意访问。当然过于严格的策略，则会“伤敌一千，自损八百”，因此我们还是要找到一个合适平衡。

运维团队经过部分规范化、自动化，已经能够快速交付规格一致的服务器了，接下来我们的需求就是如何进一步纳管服务器并对外提供统一登录。

我们无论做什么规范，目的都是避免差异性；其次团队中每个人的习惯不同，没有规范必将导致服务器配置差异五花八门，无形中增加了运维的难度；最后目录的规范统一可以给后续的自动化打下坚实的基础。

Cobbler+Ansible实现了操作系统的安装、配置自动化，可以在一定程度上解决运维工作中的基础运维部分，其更深远的意义在于有效避免了因配置参数混乱导的生产问题，为日后更多的自动化接入打好了基础。

运维规范如何生成？一文介绍了怎样从平常工作中提取运维依据，实现运维规范的落地。接下来我们就要按照运维框架分层继续推进标准化工作了，不要以为"落地"是说着玩的！

运维规范只是自动化的前提，有了规范只是完成了万里长征的第一步，接下来我们只需要严格按规范去执行、不断的进行优化，剩下的都是水到渠成的事儿了。

从zabbix监控的现状及cmdb的角色定位，阐述了二者的关系，更引申出了日后监控系统的目的及其可持续性的成长方式。当然运维并不是脱离了这些就没法干，而是在合适的阶段选择适当的工具，保证业务的可靠性。

平台化监控架构可以为我们构建系统监控体系提供了思路，剩下的就是我们如何从细节性问题入手，利用技术手段去解决问题了。

各位小伙伴，近期技术文感觉发的有点多，不知是否给大家在工作中解决实际问题带来了一些灵感。为什么这么说呢？因为正是文章中涉及的细小知识点积少成多，让我从零碎繁忙的运维工作中得到了一定程度的解放。

在运维自动化建设过程中，主要还是基于运维规范、运维工具、流程控制等方面的结合，而不是分而治之。对于运维来说并没有要求有很高的开发能力，因此我把此过程称之为接地气的自动化建设