Я работаю в небольшой продуктовой компании. Я являюсь частью команды размером 4, которая создает конвейер развертывания для нашего продукта.
Моя компания также наняла внештатного консультанта DevOps, который помогает нам в управлении нашей платформой CI / CD. У этого парня около 15 лет опыта, он горячая голова, и я ему не доверяю.
Мы используем инструмент jenkins CI \ CD и установили его на экземпляр aws ec2. Все мои товарищи по команде и консультант DevOps имеют root-доступ к экземпляру ec2.
Сегодня в 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
Я сделал быстрый поиск в Google и обнаружил, что команда tc используется для управления трафиком. Он используется для имитации задержки в сети, вызывая задержку или потерю пакетов.
Из приведенных выше команд похоже, что он удалил некоторые правила, которые вызывали потерю пакетов или задержку исходящих пакетов.
Насколько я понимаю, этот парень добавил некоторые правила с помощью команды tc, которая вызвала задержку или потерю пакетов, из-за которой наш пользовательский интерфейс jenkins не загружался, а затем удалил эти правила, которые устранили проблему.
Я разработчик и у меня мало опыта в системном администрировании и DevOps. Может ли кто-нибудь подтвердить это, чтобы я мог обратиться к руководству и подать официальную жалобу.
Невозможно определить состояние системы до того, как эти команды были запущены, и, следовательно, невозможно определить, удалял ли он внесенные им изменения, или же работа, которую он проделал, на самом деле не должна была вызвать никаких изменений.
Чисто на основании того, что было выполнено, можно предположить, что там был контроль движения.
Обратите внимание, что tc используется не только для задержки или потери пакетов, но также для изменения приоритета трафика и распределения полосы пропускания. Вполне возможно, что то, что парень пытался сделать, было предназначено для пользы, но как-то облажался.
Назовите меня циничным, но что с at now +38 minutes? Это явно требует, чтобы некоторые команды и / или скрипт были выполнены через 38 минут. Конечно, это не записывается в истории bash.
Может случиться так, что снова действует дисциплина очереди, и именно это at делал. Вы можете попробовать войти в эту систему и запустить tc qdisc ls чтобы проверить, был ли изменен qdisc по умолчанию.
В любом случае, если этот парень скажет, что удалил некоторые временные файлы, я бы определенно был циничен - ни одно из того, что он там сделал, не удаляло временные файлы.
Я не мог понять, что за echo команды пытались манипулировать. По крайней мере, в командной строке нет перенаправления (сама команда предполагает, что ее следует где-то поместить в файл).
Я бы посоветовал еще немного покопаться, чтобы увидеть, какие текущие qdiscs находятся на месте.
После ответа @Matthew Ife вы можете ознакомиться с at каталог спула и изучите доступные там файлы. В моей системе он находится в /var/spool/at/spool и вы можете увидеть, если и что запланировано для выполнения в будущем.