我在一家小型产品公司工作。我是 4 人团队的一员，该团队正在为我们的产品构建部署管道
我的公司还聘请了一位自由职业的 DevOps 顾问来帮助我们管理 CI/CD 平台。这个人有大约 15 年的经验，而且脾气暴躁，我不信任他。
我们使用 jenkins CI\CD 工具并将其安装在 aws ec2 实例上。我的所有团队成员和 devops 顾问都拥有 ec2 实例的 root 访问权限。
今天上午 11 点，jenkins UI 突然停止工作。加载速度非常慢。我们重启了 jenkins，增加了堆大小，并尝试了所有我们能想到的方法，但还是找不到解决办法。
我们花了大约 3 到 4 个小时尝试调试问题，突然这个人（devops 顾问）来了，并在 5 分钟内解决了问题。当我问他做了什么时，他说他删除了一些临时文件。出于怀疑，我立即去检查了命令历史记录
他运行了以下命令
8 tc qdisc del dev eth0 root
229 tc qdisc del dev lo
230 tc qdisc ls
231 tc qdisc del dev lo root
232 echo -n "CPU" "100 99 166"
233 echo -n "CPU" -n "100 190 188" -n
234 yc qdisc del dev eth0 root
235 tc qdisc del dev eth0 root
236 tc qdisc del eth0
237 ifconfig
238 tc qdisc del eth0 root
239 tc qdisc del eth0 root 1
240 tc qdisc del dev eth0 root
241 at now +38 minutes
我快速谷歌搜索了一下，发现 tc 命令用于流量控制。它用于通过引入延迟或数据包丢失来模拟网络延迟
从上述命令来看，他似乎删除了一些导致数据包丢失或传出数据包延迟的规则。
我的理解是，这个人使用 tc 命令添加了一些规则，这导致了延迟或数据包丢失，因为我们的 jenkins UI 无法加载，然后删除了那些规则，从而解决了问题。
我是一名开发人员，在系统管理和 DevOps 方面经验不足。有人可以确认这一点吗，以便我可以向管理层提出正式投诉。
答案1
在运行这些命令之前无法判断系统的状态，因此无法判断他是否正在删除他所做的更改，或者他所做的工作实际上是否不会导致任何更改。
单纯从所执行的操作来看，这表明当时已经实施了交通管制。
请注意，这tc不仅用于延迟或产生数据包丢失，还用于重新确定流量优先级和带宽分配。这家伙试图做的事情很可能是有益的，但却以某种方式搞砸了。
你可以说我愤世嫉俗，但 是什么at now +38 minutes？这显然是在请求 38 分钟后执行一些命令和/或脚本。当然，这不会记录在 bash 历史记录中。
可能是队列规则又出现了，这就是它at正在做的事情。您可以尝试登录此系统并运行tc qdisc ls以检查默认 qdisc 是否已被更改。
无论如何，如果这个家伙说他删除了一些临时文件，我肯定会持怀疑态度——他所做的一切都不是删除临时文件。
我无法识别这些echo命令试图操纵什么。至少命令行中没有重定向（命令本身建议将其放在某个文件中）。
我建议进一步研究一下，看看当前的 qdisc 是怎样的。
答案2
根据@Matthew Ife 的回复，您可以查看atspool 目录并检查其中可用的文件。在我的系统中，它位于/var/spool/at/spool，您可以查看是否计划在未来执行以及计划执行哪些内容。