yanggd1987的专栏

如果没有一个统一的代码仓库的管理规范，无论在测试阶段还是在生产上线过程中都将会是“一地鸡毛”。在此我们选择开源分布式版本控制系统Git作为代码仓库，并给大家介绍下已在企业生产实践中经过验证的Git分支管理规范。

在DevOps中有研发效能，如今放到运维自动化中，我们也需要重视下运维效能，运维也要理直气壮的用数据说话！

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

简述“对数据要有敬畏之心”这个主题是同事在一个早会分享时提出的，却直接引起我心中的共鸣。前几年各种删库跑路事件、Facebook宕机事件仍不绝于耳，虽然大家将“删库跑路”当作一个调侃与谈资，但上升到“对数据要有敬畏之心”的高度，作为运维我们就要居安思危，防患于未然。数据的定义从运维的角度，数据不是独立存在的，它存在于日常运维过程中的各个环节，如例行维护、变更、故障处理等。因此如果我们只考虑数据本身则意义不大，要从数据存在的各个环节去分析。在此我们将其大体概括为：数据备份文件系统+例行维护数据

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

CI/CD不仅能够在企业DevOps进程中发挥重要作用，其实在运维自动化过程中也能做到足够有效的支撑。因此如果我们只将其当作成一个打包工具就大错特错了，其带给我们思想上的转变则更加有意义。

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

需求无论是在spring boot 还是spring cloud 项目中，随着应用的不断增多，JVM参数的统一管理的重要性就会凸显出来，否则你可能会遇到几个问题：Java进程出现性能问题，无GC日志支撑提供重要信息；OOM异常频发，无法通过dump文件进行分析定位；JVM堆内存设置规格不一致，被动等待出问题时发现；作为运维，虽然没有超强的能力去最终的定位、分析、排查问题，但并不意味着我们就可以袖手旁观，那么我们能做什么呢？首先，我们要知道Java进程默认参数启动并不会打印某些我们需要的日

简介对于信息类网站，总是会被各种不同目的的爬虫、采集器等不断的抓取或恶意访问，这些会让网站不堪重负，导致页面无法正常访问，极大的影响用户体验。针对此种情况，我们就需要对所有的访问来进行访问控制。此时Web应用防火墙（Web Application Firewall，简称 WAF）就可以助我们一臂之力，它可以为网站提供一站式安全防护。WAF可以有效识别Web业务流量的恶意特征，在对流量进行清洗和过滤后，将正常、安全的流量返回给服务器，避免网站服务器被恶意入侵导致服务器性能异常等问题，保障网站的业务安全和数

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

前言前面《运维思索》系列文章已经将我们的自动化运维之路铺好，接下来我们要进入的是基础设施自动化落地。本文希望能够将《运维思索》系列与之前分享的一些文章进行有效的串联，让历史文章不再孤单，再次发挥余热。串联在运维思索：运维管理与运维自动化一文中讲到了运维自动化的几个阶段：操作自动化>场景自动化>智能化，其在基础设施层的落地主要体现为：操作自动化运维思索：操作系统配置规范化、自动化一文，基于配置规范结合ansible实现了部分功能的操作自动化：（1）操作系统配置初始化、用户配置自动化、

简述各位小伙伴，近期技术文感觉发的有点多，不知是否给大家在工作中解决实际问题带来了一些灵感。为什么这么说呢？因为正是文章中涉及的细小知识点积少成多，让我从零碎繁忙的运维工作中得到了一定程度的解放。相信认真读过的小伙伴，一定会觉得工作中并非只有什么高大上的技术才能解决痛点，恰恰相反，正是那些我们平时忽视的细节才是问题的要害。那么只有切中要害，我们才能对症下药。因此接下来一段时间，我可能会陆续分享运维过程中对一些问题的思考，希望给大家带来一定的启发。本次分享的是确立一套运维监控体系，构建可持续成长的监控平

简述各位小伙伴，近期技术文感觉发的有点多，不知是否给大家在工作中解决实际问题带来了一些灵感。为什么这么说呢？因为正是文章中涉及的细小知识点积少成多，让我从零碎繁忙的运维工作中得到了一定程度的解放。相信认真读过的小伙伴，一定会觉得工作中并非只有什么高大上的技术才能解决痛点，恰恰相反，正是那些我们平时忽视的细节才是问题的要害。那么只有切中要害，我们才能对症下药。因此接下来一段时间，我可能会陆续分享运维过程中对一些问题的思考，希望给大家带来一定的启发。本次分享的是运维管理与运维自动化的思考。一、运维的工作

简述作为运维团队的一员，当你登录服务器第一时间是否是以下行为：确定应用的启动目录、数据目录、日志目录、启动用户；确定应用如何启动及是否有开机自启动或守护进程；确定服务器的日常脚本目录、软件源码目录、公共目录等；如果你存在以上行为，那说明你们的团队需要做目录管理规范了。这是为什么呢？首先明确的是我们无论做什么规范，目的都是避免差异性；其次团队中每个人的习惯不同，没有规范必将导致服务器配置差异五花八门，无形中增加了运维的难度；最后目录的规范统一可以给后续的自动化打下坚实的基础。举个简单的例子：

简述各位小伙伴，近期技术文感觉发的有点多，不知是否给大家在工作中解决实际问题带来了一些灵感。为什么这么说呢？因为正是文章中涉及的细小知识点积少成多，让我从零碎繁忙的运维工作中得到了一定程度的解放。相信认真读过的小伙伴，一定会觉得工作中并非只有什么高大上的技术才能解决痛点，恰恰相反，正是那些我们平时忽视的细节才是问题的要害。那么只有切中要害，我们才能对症下药。因此接下来一段时间，我可能会陆续分享运维过程中对一些问题的思考，希望给大家带来一定的启发。本次分享的是cmdb与zabbix监控系统的融合。现状

简述运维思索：Cobbler无人值守实现操作系统安装规范化一文只是实现了对操作系统的主机名、网络、磁盘分区的安装规范，但此时还不能够直接用于生产，因为操作系统还有很多配置没有进行优化，接下来的工作就是要对操作系统进行配置规范化。思路让我们先停止手头无休止的工作，来简单回想下曾经配置过数不清的服务器，配置过程是否和以下有所类似：yum源配置安装常用工具gcc、gcc-c++、cmake、wget、iftop、supervisor等环境变量配置a.终端超时时间b.优化history

简述运维思索：运维规范如何生成？一文介绍了怎样从平常工作中提取运维依据，实现运维规范的落地。接下来我们就要按照运维框架分层继续推进标准化工作了，不要以为"落地"是说着玩的！本文我们介绍"IT基础设施层"中比较基础的工作：服务器的操作系统安装，涉及到的场景是服务器上架批量安装操作系统。如果服务器数量较少，我们可以通过idrac或现场安装，但是服务器几十台甚至上百台可能就不适用了，此时我们就需要无人值守安装。不管数量多少，彻底和人工说88，在此推荐Cobbler。部署1.安装yum install h

简述前面的文章老说“运维管理”、“运维自动化”，可能大家都听烦了，大道理谁都会说，能不能来点干货，把这些“大白话”落地？我自己也不断在想是否应该将这些分享出来，因为都是自己在工作过程中的个人理解，都是野路子。但换个角度，运维的工作并不是简单的修修补补，而是给业务赋能，让自己实现价值的，因此接下来的文章更多的是进行落地。运维框架运维思索：运维管理与运维自动化一文中我们从运维工作中提取了运维框架（红色代表缺失），由基础设施层、数据层、应用层、管理层、展示层组成，生成了我们最终的运维体系。下面我们从以下

简述继运维思索：Cobbler无人值守实现操作系统安装规范化、运维思索：操作系统配置规范化、自动化两篇文章后，运维团队已经能够快速交付规格一致的服务器了，接下来我们的需求就是如何进一步纳管服务器并对外提供统一登录。为了实现这一需求，我们需要借助于堡垒机。在此我们特通过JumpServer的应用来·深度体验如何纳管服务器并实现统一登录。传统管理方式传统管理方式给运维团队及开发、测试人员带来以下问题：开发、运维、测试登录生产环境，需要进行二次跳转，操作繁杂；开发、运维、测试登录各种环境服务器，强烈