读本好书 《运维前线》

8 April 2019   3538 words   ~8 mins
#book #nginx #ops

Table of Contents

前

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

喜欢就去追寻

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

简介

  • 书名：运维前线
  • 作者：云技术社区
  • 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。这两种方式分别就是 sysVinit和 systemd。如果说性能和速度， 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.target 和 graphical.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. 愿赌服输需要资本

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

后

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

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

← prev next →