读本好书 《运维前线》

这本书好久之前以及借到手了,可是各种原因,又是迭代阅读法,反反复复好多次才给读完(翻了一遍)

喜欢就去追寻

互联网本来是安全的。自从有了研究安全的人之后,互联网就变得不安全了。

简介

  • 书名:运维前线
  • 作者:云技术社区
  • ISBN:9787111556978

这本书更像一个案例集,里面写了各种各样的时间案例,以及解决方案。还有各种关于运维职业的思考。

大胆的往前走吧,一切皆有可能,唯独那些实现不了的,都是我们人的问题,无它。

利用 Facter 和 Django 快速构建 CMDB

CMDB(Configuration Management Database),称为配置管理数据库,惯称为资产管理系统,实现对主机资源的管理。
书中的的构建的系统,使用 Facter 来实现主机的基本信息的获取。结合 Puppet 来实现主机的管理。

在CMDB中,使用 Python 来进行 Facter 的调用以及对输出的数据的统一处理。其中的示例代码如下(这里用了一个很好的module:commands,可以方便的执行系统命令,获取返回值与内容):

def handle_command_message(command):
    status, content = commands.getstatusoutput(command)
    if status == 0:
        return content
    else:
        return

通过对 facter 的执行得到各个主机的信息,之后进行集中处理。
后面的细节是Django的基本工程建立,以及拉去每台主机的信息的功能实现。

人是整个系统中最薄弱和不可预测的一环。如果使用人工来进行维护,那么数据不准的情况是 100%会出现的。

集中配置管理工具 puppet

常见的运维工作流程包括:安装系统,优化系统与配置,安装软件,配置软件,添加监控,检查。当服务器规模变大之后,这一切会变得很繁琐了。Puppet 一个跨平台的集中配置管理系统,就是来解决这个问题的。

在每个agent上面安装软件包

如果是没有pp 的情况下,需要登陆每台主机进行控制和部署,十分的繁琐。有了 puppet 时候,可以很方便的使用一个 pp 文件进行安装。

package {
    ["screen","ntp","sysstat"]:
    ensure => "installed"
}

这样就可以很快速的实现全部服务器的统一安装。

自动同步yum源,(文件)

一样何以使用简单的配置文件:

file {
    "/etc/yum.repo,d":
        source => "puppet://service/files",
        group => root,
        owner => root,
        mode => 664,
        recurse => true,
        force => true,
        purge => true
}

之后服务端会向客户端自动的推送配置文件,之后各个的客户端会更急配置文件自动的更新自己的repo。

快速同步 www 目录

当有多个web服务器的时候,那么 www 的文件的同步就显得很重要了,(前面自己一直是用了 NFS 会不会导致性能下降),

iptable

这个是 linux 的一大神器了,可是自己用的少,找时间开专题

systemd 来进行linux 的服务管理

很多自己编译的东西用各种各样的方式跑着,什么 nohup ,crontab,脚本的,各种各样,所以这里,就刚好加深一下对于服务的理解。

平时用到的一样,分了 debian和redhat系,在cent里面使用的是 systemctl 在ubuntu里面用的是 service。这两种方式分别就是 sysVinitsystemd。如果说性能和速度, systemd 就是更快更好了,而且不好出现 服务启动失败导致的jam。sysV 里面如果服务启动失败了就会堵塞启动进程。


使用 ps 1 命令,就可以很直接的看到我们当前的系统服务是那种方式。
file

运行级别

在 sysV 里面使用 init 来指定当前的运行级别,特殊的有 init 0 是关机, init 6 是重启。在 /etc/rc.d/rc 里面分各个启动级去有了不同的shell。init 3就是命令行启动 init 5 是图形化启动

而在 systemd 里面,对这些文件进行封装,变成了target。所以有了 multi-user.targetgraphical.target。使用 ls -l /lib/systemd/*.target

file


  • 自启动添加 chkconfig --add [servicename]
  • 自启动开启 chkconfig [servicename] on

systemd 工具

用来分析启动时间 systemd-analyze

  • systemd-analyze blame 列出所有的服务启动时间
  • systemd-analyze plot > img.svg # 打印出矢量图
  • journalctl -u -f [servicename] 查看服务的日志。

PHP 运维实践

由于相关业务接触不多,简单了解这些。

Nginx,php-fpm 支持平滑重启,因为设计的是多进程模式,而mysql和Tomcat 不支持平滑重启,因为后者的设计是多线程的。

性能分析

  1. 简单的top查看负载
  2. strace -p <PID> -T 系统调用信息
  3. strace -p <PID> -c 系统调用次数和时间统计

PHP 故障处理与监控

故障处理绝对不能依靠用户反馈,需要更好更快的分析问题以及故障。(更重要的需要理解业务的整体的结构和框架,了解是哪一部分的问题)

  • 502 bad gateway 可能是PHP执行太久,达到了fpm 的超时,在日志里会有 SIGXXX 的情况。
  • 502 一般处理办法,是否需要延长超时,而且开始分析 php 或者 sql 的慢日志
  • 503 service temply unavailable,可能是 upstream 连接问题,即fpm死掉
  • 503 一般处理办法,对nginx的转发负载进行分析,是否需要横向扩容
  • 504 gateway timeout,nginx存活,但是 fpm无法及时给出响应,一般是 访问量突增导致。
  • 504 一般处理办法,资源进行横向扩容,fpm

监控方法:

  1. 加入 URL 的响应拨测,及时发现问题
  2. PHP-fpm 的进程监控,
  3. 错误日志的数量监控
  4. 。。。。
    通过监控系统上报到监控平台。

故障处理方法

  1. 快速修复代码问题
    直接回滚
  2. 弹性调度
    自动的扩缩容,难点在于:

    • 应用服务的无状态化(比如没有 session,没有业务数据,可以使用分布式存储进行管理)
    • 自动扩缩容对自动化要求程度高
  3. 柔性可用
    一时无法处理的问题,考虑柔性可用,牺牲不重要的,保证核心功能重要运行。

服务器交付那些事

除了技术,这书里面还有不少软技术。
关于在机房里面,大量服务器上架时候遇到的各种问题,

Nginx Web 服务优化实战

这一部分就和自己息息相关了,看了之后收益不少。

基本安全优化

比如关闭服务指纹 server_token off ,这样不会回显版本号。通过重新编译可以修改服务名称。

性能优化

worker

对 worker 的数量进行设置,因为默认的是 1,另外对CPU 的亲和性设置。

user  nginx;
worker_processes  4;
worker_cpu_affinity 0001 0010 0100 1000;

高效文件传输

使用 sendfile 比read/write的IO高效许多,tcp_nopush 会把响应压缩为一个文件发布

sendfile        on;
tcp_nopush     on;

GZIP

使用 GZIP 对静态文件进行压缩,节约传输带宽。前面有涉及到()

expires

Nginx 服务器可以给静态文件设置 expires,这样可以在客户的浏览器进行静态文件缓存,无须再次请求。

根据拓展名拒绝程序和文件访问

    location ~^ /img/.*\.(php|php5|sh|pl|py)$ {
        deny all;
    }

防止非法恶意解析请求

也就是 没有通过域名进行访问,而是直接使用 IP 进行访问。

粗暴的方法如下

server {
    listen 80 default_server;
    server_name _;
    return 501
}

温和一点的重定向:

if ($host !~ ^www/.example/.org$) {
    rewrite ^(.*) http://www.example.org$1 permanent;
}

使用 referer进行防盗链配置

具体的配置,之前用过,就不赘述了。

根据功能拆分后台集群

根据功能拆分后台集群,是的不同的业务功能有不同的主机服务,大大提升安全性能。

nginx 控制请求速率

在 http 域中定义: limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s 相当于定义了请求的规则,10m的内存,允许一秒一次的请求。
在 server 的域里定义 limit_req zone=one burst=5 定义前面的请求规则,且可以有5个等待请求。

求职者与面试官

这个可就是最软的东西了。

职业规划从入职开始

A职位和B职位我到底选哪个先向业内人士了解每个行业的发展趋势,职业特点,和技能要求,再结合自身的性格和优缺点来进行选择,

如果你迷惘到自己都不了解,那么别人指出的道路又怎么能一定正确呢?

规划是需要不断修改的,不是一句 五年成为 CTO 这么简单,松下幸之助的松下250年计划,无法帮松下走出困境

面临的观察和考量

大公司做事情比较规范,对新人的影响是积极的。其次考虑创业公司,之于小公司创业公司能学到更多的东西。但是关于创业公司,只建议工作不足两年的新人去考虑。


在面试过程可以进行反问:

  1. 我们的近两年的发展目标是什么?要到什么程度
  2. 我们目前面临的最大需求是什么?
  3. 我的这个岗位的未来三年的发展方向是什么?进一步发展还需要那些要求

候选人为什么失利

  1. 搞不清状况,面试的时候把清楚世纪,不是上来问薪水
  2. 不要狐假虎威吹嘘自己
  3. 技术深度不足,工作了七年的工程师的技能还是停留在 ICM级别(Install Configuration & Management)
  4. 动力不足执行力差
  5. 可靠性差

如何突破职业瓶颈

某个岗位上长期无法突破,工作本质没有变化,薪酬待遇也是停滞不前,职业竞争力下降。这就是到了自己的职业瓶颈。

改变目标不如改变方式,改变环境不如改变自己

时间管理四象限

  1. 紧急重要
  2. 重要不紧急
  3. 紧急不重要
  4. 不紧急不重要

平时多工作在 第二象限。

你是否应该投身创业公司

  1. 30%能买断几年的青春?
    创业公司的特点就是设备飞速扩张,团队人员不齐,大量初始化工作需要有经验的实施团队。也就是一旦选择就是 从零开始。但是一般的涨薪可能在 30% 左右,意味着用 30% 的钱买断了 3年的青春。因为较比之前的公司无法得到很好的发展。
  2. 财务自由是赌徒的想法
  3. 成功不可复制,没有充要条件
  4. 愿赌服输需要资本

    经常听人讲,年轻热血赌一把,错了不后悔,大不了愿赌服输。要知道愿赌服输是要资本的,没资本输的人也没资本说这句话。
    如果你年轻,又没有家庭负担,那么很好,这就是你输得起的资本。
    社会喜欢同情弱者,年轻就是犯错的资本。

难得专注的一下午,软硬皆有的一本书,后面的内容对自己的触动还是蛮大的。

我觉得,他的人生非常令人羡慕。不是因为取得的成就,而是因为每个人生阶段,他都在干不一样的事情:年轻时是程序员,中年时是科学家,老年时是新能源企业家。美国总统特朗普也是这种情况:年轻时是房地产商,中年时变成电视明星(《学徒》一口气拍了十季),老年时变成了总统。人生就好像一次旅行,不同时期能够从事不同的领域,就好像看到了不同的风景,体验了不一样的人生。

留下点什么吧