开发工作自不必说, 与大家平素写代码并无二致. 这篇文章主要讲的是我运维过程中相关的问题, 也为大家推荐几个好用的工具.

这篇文章前半部分整理了一下我在工作中遇到的一些运维问题, 算是与大家收货吧. 后半部分主要介绍Termux这个小工具. 另外Windows下的ssh环境配置, 我应该会再开 一个博客, 写写自己的关注点.

我的运维工作

从我的角度来看, 运维的一些事务其实是那些不能自动化的工作. 假如我们的代码更加完善, 自动化程度更高, 那么, 运维的工作其实可以逐渐减少.

其实运维工作并不是说运行维护就可以了, 要分好多种情况来看, 下面我从几个不同的方面 来看看目前接触的一些运维事务:

按紧急程度来分

  1. 不紧急, 这些事务主要是一些比如定时脚本超时之类的报错, 平时我们都会选择性的忽略, 有些脚本需要操作数据库, 但是它慢, 所以耗时长也是可以理解的. 只要相邻两个脚本 之间别一起运行, 基本就可以了, 平时收到的报警最多.

  2. 一般紧急, 比如一些容器的CPU, 内存这些超出了配额, 有些时候可能访问量激增什么的, 这个目前就需要手动来调整. 虽然超出了配额, 但是线上环境一版也不会直接给你关闭的, 只要调大阈值把报警屏蔽就好.

  3. 紧急, 有些情况下, 机器会出现死机的情况. 这时候, 一般要联系SA来重启机器了. 我们其实无能为力, 只能尽量减少死机次数, 提高稳定性. 在我看来, 死机并不是特别紧急的, 因为Nginx会将这些死机的节点屏蔽掉, 马上切到其他的节点服务, 有些服务可能会瞬断一下就会恢复了.

  4. 特别紧急, 特别紧急的情况, 是与我们的平台相关的问题, 比如突然不能部署了, 或者某台机器中的部署程序出现了问题, 虽然对现有服务没有影响, 但这是真真切切 与服务稳定性相关的, 标志着我们能够达到几个9.

按处理方式来分

  1. 能够直接屏蔽的报警, 可以直接在管理员界面完成.

  2. 需要暂时屏蔽, 应用也要重新部署或是其他操作, 也可以在管理员界面完成.

  3. 需要使用ssh连接机器, 类似死机重启后的检查, 或是无法部署时的修复.

按处理人来分

  1. 平台管理员处理, 上面遇到的所有问题, 其实都要有平台管理员

  2. 管理员联系开发者处理, 比如访问量大了, 增加机器总是要通知开发者处理一下的

  3. 管理员联系SA来处理, 上面也说道了, 有关死机之类的问题.

DevOps的苦楚

我既是这个系统的开发者, 也是维护者, 也类似一种简单的DevOps. 其实开发还好, 只需在上班时间处理一下工作. 不过运维可能就要占用一些生活上的时间, 而且, 基本无法 避免.

工作时间

一般领导也没有给我分配特定时间要做完的任务, 因为有运维的工作在. 突然出现了问题 需要花费一天或是半天来处理, 开发进度有些时候并不那么容易掌控.

非正常工作时间

没有了具体的开发任务, 但是也需要待命, 类似春节这种, 就需要与同事轮流值班, 避免出现问题无人解决, 与SA一样需要待命.

但是非工作时间, 很大程度上就不在电脑前了, 平时也就带个手机出门, 出了问题需要 连到机器上真的挺麻烦的, 后来我想了两种办法: 1. 有网吧就去网吧, 简单配置一下SSH环境 就可以用了; 2. 手机上安装ssh软件, 虽然屏幕实在小, 但也能撑一下, 毕竟比电脑好带.

Termux

我认为, Termux是Android我用过最为舒服的一个终端工具了(我只用来ssh).

Android上类似的ssh工具还有JuiceSSH, 不过这个软件掉链子, 我连秘钥都没法考进去, 最后直接放弃了.

Termux的主要功能其实不是ssh, 它是类似于子系统一样的环境, 猜测是利用了chroot, 只是顺便可以安装ssh工具.

这个软件自带了一个包管理工具, 一般常用的软件包都是有的, 安装openssh自然不在话下, 另外也可以安装tmux, 以及htop, 对我来说, 这些软件已经完全足够了. 毕竟我是 连接远程的服务器来工作的. 而且Termuxtmux的支持完全没有问题, 你可以开多个 窗口, 只要你不嫌小.

安装软件包

pkg_install

htop

htop

ssh连接机器

openssh支持config文件, 你可以参考我的OpenSSH系列来配置环境

ssh

另外

如果有运维需求, 我们也可以交流, 我也在寻求兼职运维的工作