zl程序教程

您现在的位置是:首页 >  其他

当前栏目

一个运维人员的编程思维1

2023-03-20 14:52:36 时间

前言

作为一个运维人员,虽然不必像开发一样得精通一门或好几门语言,但是基本的编码能力还是要有的,如果懂得一些基础的编程技巧,就可以给自己的日常工作省不少事儿,一些重复性的工作也可以交由代码来完成,使自己的工作不必那么枯燥,同时也少了很多潜在的风险,因为相对于机器,人的速度太慢了,人并不擅于处理重复性的工作,人也更容易出错


懒惰

我一直都觉得懒惰是一个运维工程师应该具备的优秀品质

一个优秀的运维工程师应该有大量的闲暇来思考和优化现有的技术架构,学习先进的技术与理念,更透彻地理解业务需求,让技术架构能够更好的服务于当前和未来的业务发展,而不是频繁被眼前的琐事打断,视野局限在一个非常狭窄的范围

那如何才能有大量的闲暇呢?

将事情交给机器做,然后通过持续优化现有系统架构,就可以逐步脱离疲于奔命的处境


编码能力

想懒惰,首先得付出一点点勤奋将自己打磨得具备懒惰的能力

而这种能力就是编码能力,有了编码能力,机器就会乖乖听话,按照 寡人 的旨意,唯命是从

一般而言运维常用到的会是shell、perl、python、ruby

它们有一个共同特点,就是都属于解释型语言,解释性语言是在运行的时候才将程序翻译成机器语言,相较于编译型语言(C,C++,Golang)要慢至少一个量级,但是绝大部分的运维场景中,对于速度的要求并没那么苛刻(远远比不上一个客户端或应用服务对响应的要求,响应速度严重影响 用户体验 ),甚至基于当前主流的软硬件平台我们基本感知不到两者之间的明显差异,然而解释型语言的简洁和灵活却给运维带来了很多便利


编程思维

在这里我也并不准备就编译型和解释型展开太多,也不想就哪一种运维常用到的语言进行深入的剖析,相关的网站和书籍多的是,比我讲的更专业,这里我只想分享一下一个运维人员的编程思维

Tip: 当然并不代表对开发人员就毫无用处,思维是比较抽象的,大部分情况下是脱离具体应用场景的,因为它来自于更广泛的观察,正因如此,也可以反过来指导更广泛的生产实践


概要


总体方向

下面是总体的进阶方向

复杂的事情简单化,简单的事情重复化,重复的事情自动化

完成了上面的,就基本满足要求了

但是要想更进一层就涉及到 可视化智能化


复杂的事情简单化

主旨就是对于一些难以一蹴而就的事情,进行分步处理

将事情拆解成小的、简单的步骤后往往就变得可行

怎样将一头大象装进冰箱里? 就是一个很好的问题,不要习惯性的反弹回来:“这怎么可能!!!”,而是先初步将这个任务进行一下分解

分解方式因人而异,并无定法,主要以自己或团队最为高效方便的姿势来拆解,当然也可以参考一些最佳实践,这个过程就是在提升其总体的操作可行性

这里分成三个步骤:

  • 第一步,打开冰箱门
  • 第二步,把大象装进去
  • 第三步,关上冰箱门

第二步不明显扯淡么,对的,不过先不要反弹回来嘛,其实第二步又可以当成 一头大象 ,将家用冰箱更换成集装箱型的工业运输冰箱,或仍然使用家用冰箱,但将大象拆解,都是可以尝试的方向

就这么一步步拆解下去,最后就将难以处理的事情,变得可行

现实场景中往往比这个要复杂很多,也可能因为中间步骤的调整牵连到了前后步骤的变动,但这个不重要,重要的是这个思路,拆解问题这个方向是在持续提升一件事情的可行性

Tip: 当然现实中,并非给出了技术可行的解决方案就一定会执行,因为解决方案的制定和实施都会产生成本,更高层面的管理者眼里还有一个经济可行性的考量,当然这就扯远了,今天只论技术思想

运维中很好体现这一思想的就是Ansible的Playbook

下面是一个安装 apache http server的示例: