一个工作中的案例，使用systemd工具，分析服务启动时间。

先描述一下问题：

在一套测试环境中，小明要验证可靠性，就把一台物理机重启了，却发现系统启动后，WEB页面很久都打不开。小明又重启了其他的主机，发现只有2台主机有这个现象，而且是必现的。

从我们的项目日志分析，确实在系统启动30多分钟后，我们的服务才正常运行，同时也发现，我们的服务开始启动，已经是系统启动30分钟后了，那么问题就在于，为什么这个服务，这么晚才开始启动呢？

再解决一下问题：

我们的项目部署在Centos7.5上，由systemd托管服务的生老病死。因此考虑从systemd的日志查看，果然，系统启动后30分钟，才开始启动我们的服务，而我们的服务实际启动非常快。那么这之前，systemd在干嘛呢？

这时候，systemd-analyze可以派上用场了，分析systemd的官方神器。

systemd-analyze blame # 这个看每个服务启动时间，从长到短。
systemd-analyze plot > /root/sys-plot.svg #这个是服务启动时序图，可以用浏览器打开。
systemd-analyze critical-chain atd.service # 单个服务启动信息

从结果我们很明显的看出，linux启动后，首先启动了1号进程 systemd（以前是initd），由systemd负责所有其他进程的管理：

systemd首先启动了linux内核（kernel, initrd）。

然后按照顺序启动systemd配置的服务单元。优先级较高的有网络、文件服务、时间同步等等。

然后再启动应用层的服务。而在我们的服务启动前，iscsi服务启动耗费了30分钟，阻塞了后续服务的启动。

结果

检查iSCSI配置发现，有测试人员在两台主机上配置了iSCSI存储，而对应的存储服务端的环境已经拆掉了。导致iSCSI启动尝试发现存储时一直失败重试，直到30分钟超时失败。
修改完配置后，重启主机一切恢复正常。