简述《运维思索》介绍了一系列运维规范、运维管理及自动化的文章，主要分享的是运维自动化建设的部分想法与思路。站在读者的角度，或许只有我自己明白，那么它们在整个运维自动化建设中到底处于什么位置、发挥着什么作用呢？先来分享一张比较初步且接地气的图：图中所用到的运维工具应该都是我们比较熟悉的且常用的，从运维框架的层次来看：基础设施层，Vsphere虚拟化、物理机等；数据层，数据库、elk、缓存等；应用层，

在项目的开始阶段，我们需要投入更多的精力去分析需求、总结现有数据、确定需求、为寻找解决方案做规划，因此非常重要，只要保持一个清晰的思路，相信我们就成功了一半。而后续方案交流中的技术细节，我们需要做的是选择题，找出一套适合我们的方案即可。

需求《蓝鲸之路》系列文章我们通过蓝鲸标准运维打通了zabbix、jumpserver，虽然实现了虚拟机从创建、jumpserver资产录入到权限分配、cmdb资产录入这一套完整的上架流程。但是cmdb、jumpserver、zabbix之间的资产及分组关系不是统一的，团队需要花费一定的精力去维护及团队间信息同步，在此cmdb并没有起到统一数据源及提供数据支撑的作用，因为zabbix、jumpser

`监控和业务分离`一直是我们所忽略的问题，随着架构和业务规模不断发展，一般情况下的多维度监控虽然可以在业务应用可用性方面发挥重要的作用，但是无法做到和业务流程进行有效关联。此时就需要更懂或者更了解业务的相关人员进一步判断，这无疑大大延长了故障时间，严重影响了我们的SLA。

如果没有相应的 IaC 实践，那么管理现今这样大规模的基础架构会变得越来越困难。IaC 可以帮助我们管理 IT 基础架构需求，同时提高一致性并减少错误和手动配置。

对于安全合规基线，我们肯定希望能够对所有纳管的服务器进行批量更新，最好还可以根据最新的标准不断进行持续优化更新。因此我们使用`Ansible Playbook`进行统一管理，一方面安全合规基线配置是系统标准初始化的一部分，另一方面其也可以对基线进行单独的执行。...

磁盘类告警只是我们诸多告警中的冰山一角，虽然我们有值班人员甚至是运维团队支撑，但是也不能因为这种小问题就分散注意力，这时我们就需要考虑如何通过自动化实现。

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

基础设施的管理虽然看似简单，但还是有很多意想不到的问题会挡住我们前进的道路，正所谓”技术都是现成的，剩下都是管理问题“，同时也利用这个机会来检验团队直面困难的魄力。

需求运维是事件驱动，还是自驱动可能是我们在运维工作中不太关注的问题。事件驱动让运维止步于故障，而自驱动让运维不止于建设。持续性的运维建设就需要一套自动化的运维体系，那么我们应该从何入手？其实前期《运维思考》一系列文章已经给我们答案了，就是从运维框架入手分层建设、打好基础，记住“万丈高楼平地起，勿在浮沙筑高台”。运维框架通常讲到运维建设，我们脑海中首先浮现的是“一团麻”，因为这不是一个人、一个岗位的