одиниці
1. Вступ до штучного інтелекту в управлінні системою та мережею: ролі, межі, автентифікація та повноваження 2. Скрипти автоматизації: безпечне створення Bash, PowerShell і Python 3. Аналіз журналу та аналіз першопричини: пошук сигналу в шумі 4. Моніторинг потужності та продуктивності: читання показників і планування на майбутнє 5. Керування конфігурацією: генерація конфігурації, перевірка та фіксація дрейфу 6. Управління інфраструктурою як код (IaC): Terraform, Ansible і Plan Control 7. Управління документацією та інформацією: Runbook, Post-mortem і корпоративна пам’ять 8. Прогнозне технічне обслуговування: бачення несправностей до того, як вони виникнуть 9. Управління змінами: оцінка ризиків, відкат і вікно обслуговування 10. Безпека та оборона: використання штучного інтелекту в цілях оборони та в межах повноважень 11. Наскрізна інтеграція: керування інцидентом від початку до кінця
одиниця 2 / 11

Скрипти автоматизації: безпечне створення Bash, PowerShell і Python

Прибуток:

  • Можливість створювати сценарії автоматизації Bash, PowerShell і Python із чіткими обмеженнями та огорожею безпеки зі штучним інтелектом
  • Можливість додавати такі принципи, як ідемпотентність, сухий запуск, обробка помилок і відкат до кожного сценарію та застосовувати цикл «генерування, посилення, перевірка»
  • Здатність зрозуміти, що виконання створеного сценарію не означає, що воно безпечне, і набути звички брати на себе відповідальність, читаючи та перевіряючи деструктивні рядки.

Сценарії автоматизації: безпечне створення Bash, PowerShell і Python за допомогою ШІ

Найлютішим ворогом системного адміністратора є повторювана ручна робота: підключення до кожної машини та очищення журналів, відкриття того самого користувача на двадцяти серверах, запуск однієї й тієї самої перевірки працездатності щоранку. Це повторення відкрите як для часу, так і для людських помилок. Сценарій автоматизації — це невелика програма, яка делегує ці ітерації комп’ютеру — найчастіше написана на Bash (мові команд оболонки) у світі Linux, PowerShell (оболонці автоматизації Microsoft) у світі Windows і Python для незалежної від платформи роботи. ШІ неймовірно швидко створює, пояснює та покращує перші чернетки цих сценаріїв. Але сценарій — це не текст, це сила, що працює у вашій системі; На відміну від формули Excel, якщо вона неправильна, вона видаляє файл, зупиняє службу та обрізає доступ. Ось чому обіцянка цього підрозділу полягає в тому, що штучний інтелект пише сценарій, ви його читаєте, тестуєте та запускаєте, беручи на себе відповідальність.

У цьому розділі ви дізнаєтеся, як створювати безпечні, читабельні та доступні сценарії за допомогою ШІ; Рятувальні принципи, такі як ідемпотентність (запуск одного сценарію двічі не завдає шкоди) і сухий запуск; і ви дізнаєтесь про перевірки, через які має пройти сценарій, перш ніж запускати його у виробництво.

Чому сценарії за допомогою ШІ такі потужні?

Навіть досвідчений адміністратор може не знати напам’ять точного синтаксису циклу Bash, параметрів командлета (команди) PowerShell або блоку try/except Python. ШІ миттєво заповнює цю прогалину: ви пояснюєте намір простою турецькою мовою, і він створює робочий план. Крім того, ви можете надати ШІ існуючий скрипт і сказати «поясніть це», «додайте обробку помилок», «зробіть його більш читабельним». Це скорочує криву навчання та пришвидшує молодших членів команди.

Але з владою приходить відповідальність. У більшості випадків сценарій, згенерований ШІ, записує «щасливий шлях» правильно (якщо все гаразд); але він може пропускати граничні випадки (відсутній файл, диск заповнений, мережа не працює) або робити небезпечні припущення. Тож подумайте про створення сценарію за допомогою штучного інтелекту в три етапи: створення, посилення, перевірка.

Крок за кроком: створення безпечного сценарію

  1. Чітко напишіть намір і обмеження. Яка операційна система, яка версія оболонки, які шляхи до файлів, які права? Як «Ubuntu 22.04, Bash 5, sudo не root, запускається лише в /opt/app/logs». Неоднозначна вимога породжує небезпечні припущення.
  2. Попросіть перила безпеки. Вимагайте від сценарію «зупинки у разі збою» (встановіть -euo pipefail у Bash), запит на підтвердження руйнівних операцій, резервне копіювання перед операцією та режим сухого запуску. Ці огорожі фіксують крайові стани, які ШІ обходить.
  3. Напишіть ідемпотент. Сценарій не повинен викликати жодних помилок або пошкоджень під час другого запуску. Встановіть логіку «пропустити, якщо користувач уже існує», «створити каталог, якщо він не існує, не чіпати його, якщо він існує». Це дозволяє автоматизації безпечно працювати знову і знову.
  4. Прочитайте і зрозумійте. Прочитайте кожен створений рядок. Попросіть AI позначити деструктивні команди (rm, Remove-Item, DROP) окремо.
  5. Тест із сухим прогоном. По-перше, запустіть його в режимі «вказати, що робити» замість фактичних операцій. Якщо результат відповідає очікуванням, перейдіть у реальний режим — і спочатку на тестовій машині.
  6. Готуйте своє повернення. Чи створює сценарій резервні копії? Ви знаєте, як відновити резервну копію? Чи є журналювання, чи можете ви побачити, що воно робить пізніше?
Порада: нехай кожен сценарій деструктора містить змінну DRY_RUN=true і прапорець --apply. Поведінка за замовчуванням полягає в тому, щоб написати те, що станеться, не видаляючи нічого; Нехай фактичне видалення працює, лише якщо --apply задано явно. Ця одна звичка запобігає катастрофам, які триватимуть у кар’єрі.

три міні-чохла

Випадок 1 — Ідемпотентність збережена 3 години. Адміністратор написав скрипт, який встановив один і той же агент моніторингу на 25 серверах. Перша версія не була ідемпотентною: вона порушувала конфігурацію під час другого запуску, якщо агент уже був встановлений. Інженер змусив ШІ додати логіку «перевірити, чи встановлено, пропустити, якщо встановлено». Під час наступного вікна обслуговування сценарій випадково запустився двічі, але це не зашкодило. Ідемпотентність зробила непотрібним відновлення 25 серверів.

Випадок 2 — Сухий запуск зберіг кореневий каталог. Одна команда отримала сценарій Bash, який очищав старі резервні копії. Якщо змінна була порожня, шлях став / замість /backups/ — класична небезпека. Інженер спочатку запустив його в режимі DRY_RUN, завмер, коли побачив у виводі рядок, схожий на rm -rf /, і додав перевірку змінної (: "${BACKUP_DIR:?не може бути порожнім}"). Під час сухого запуску виявилася помилка, яка стирала весь диск перед його пуском у виробництво.

Випадок 3. Управління помилками не дозволило йому прокинутися однієї ночі. Сценарій PowerShell архівував журнали, коли диск був заповнений. Перша версія мовчки зазнає збою, якщо спільний мережевий ресурс буде недоступним, і продовжуватиме заповнювати диск. «Перевіряйте успіх на кожному кроці, якщо не вдалося, повідомте електронною поштою та зупиніться» додано до AI. Через тиждень пост було зламано; Скрипт зупинився і попередив, диск не заповнений, о 3 ночі ніхто не прокидався.

Чотири шаблони, які можна копіювати

1) Безпечне створення сценарію Bash:

Ваша роль: старший інженер автоматизації Linux. Напишіть сценарій для Ubuntu 22.04 / Bash 5. Призначення:[призначення]. Правила:- Почніть із "set -euo pipefail".- Перевірте необхідні змінні за допомогою ": ${VAR:?}".- Виконайте руйнівні операції з DRY_RUN=true за замовчуванням; Нехай справжня програма працює лише з прапорцем --apply. - Записуйте кожен крок у стандартний вихід, зупиняйтеся зі змістовним повідомленням про помилку. - Зробіть його ідемпотентним (щоб він не завдавав шкоди при другому запуску). Тоді: позначте потенційно деструктивні лінії окремо та напишіть 3 кейси, які мені потрібно протестувати перед виробництвом.

2) Зміцнення існуючого сценарію:

Підготуйте наступний сценарій до виробництва: (1) додайте обробку помилок і журналювання, (2) зробіть його ідемпотентним, (3) помістіть деструктивні команди позаду сухого запуску, (4) витягніть жорстко закодовані шляхи та секрети до змінної. Коротко опишіть кожен рядок, який ви змінили, і чому. Сценарій: [сценарій]

3) Захищена автоматизація PowerShell:

Ваша роль: експерт з автоматизації Windows. Напишіть сценарій, сумісний з PowerShell 5.1. Мета: [мета]. Правила:- Почніть із "$ErrorActionPreference = 'Stop'".- Додайте підтримку -WhatIf до командлетів деструктора (WhatIf за замовчуванням).- Оберніть кожну дію за допомогою try/catch, журнал помилок.- Жорстке кодування облікових даних; Використовуйте параметр або безпечний вхід. Позначте деструктивні лінії та напишіть кроки скасування.

4) Декодування та перевірка виразу Cron/schedule:

Поясніть наступний оператор cron простою турецькою мовою та напишіть наступні 3 середовища виконання: [вираз]Крім того, якщо моя ціль — «[мета]», чи це твердження правильне, чи ви пропонуєте виправлення? Також зверніть увагу на ефект періоду часу.

Слабка підказка / Сильна підказка

Слабка підказка:

Напишіть мені сценарій, який очищає журнал.

Ця підказка небезпечна: незрозуміло, яка ОС, який каталог, яке вікове обмеження, яка захисна огорожа. ШІ може створити одностроковий, руйнівний і неперевіряний rm.

Потужна підказка:

Ваша роль: старший інженер автоматизації Linux. Напишіть сценарій очищення журналу для Ubuntu 22.04 / Bash. Видаліть лише файли .log у /opt/app/logs, які старші за 30 днів. Правила: set -euo pipefail; Перевірити змінні BACKUP_DIR і LOG_DIR (зупинити, якщо пусті); список файлів журналу перед видаленням; Нехай DRY_RUN=true буде типовим, фактичне видалення лише за допомогою --apply; Нехай ідемпотент. Позначте деструктивні лінії та напишіть 3 сценарії, які я маю перевірити.

функція

Слабкий/швидкий скрипт

загартований сценарій

Обробка помилок

Ні, тихий провал

set -euo pipefail, try/catch

руйнівна дія

Працює безпосередньо

Сухий хід + відкритий контрольний прапорець

Перезапустіть

може завдати шкоди

Ідемпотентний, безпечний

таємне управління

жорстко закодований

Змінний/прихований вхід

скасувати

Жодного

Резервне копіювання + крок відновлення

Поширені помилки

  • Запуск деструктивного сценарію без сухого запуску. Не бачення сценарію, що містить rm, Remove-Item, DROP спочатку в сухому режимі, коштує диск.
  • Пропустити перевірку нульової змінної. Порожня змінна шляху створює / замість /backups/; : обов’язково перевірте за допомогою «${VAR:?}».
  • Забуття ідемпотентності. Сценарій ламається, коли виконується двічі, що робить автоматизацію ненадійною.
  • Секрети жорсткого кодування. Написання пароля та ключа в сценарії є витоком, коли ви ділитеся цим сценарієм.
  • Тестування на виробництві. Перший показ у постановці означає репетицію на сцені; спочатку перевірте машину.
Увага: не приймайте скрипт, наданий штучним інтелектом, лише тому, що «він спрацював, тобто він правильний». Те, що він працює, не означає, що він не є руйнівним. Сценарій може працювати на щасливому шляху та видаляти дані в граничному стані; Справжнім випробуванням є крайові випадки.

Підсумовуючи

Сценарії автоматизації виключають повторення та зменшують помилки людини; ШІ неймовірно швидко створює, пояснює та посилює ці сценарії. Але сценарій — це робоча сила: якщо він помиляється, він видаляє, зупиняє, перериває. Тому встановіть цикл «виробництво, загартування, перевірка». Включіть обробку помилок, ідемпотентність, сухий запуск і резервний варіант у кожному деструктивному сценарії. Витягніть секрети змінної, виконайте перший запуск на тестовій машині. пише сценарій ШІ; Ваша робота — прочитати його, протестувати та взяти на себе відповідальність за його використання.

Аплікаційне завдання

Виберіть завдання, яке ви повторюєте вручну у своїй роботі (наприклад, очищення журналу, відкриття користувача, перевірка працездатності). Надішліть запит на схему від AI за допомогою шаблону «Secure Bash script» або «PowerShell secure automation» вище. Прочитайте згенерований сценарій рядок за рядком і позначте деструктивні рядки. Спочатку запустіть його в режимі сухого запуску на тестовій машині, порівняйте результат із вашими очікуваннями. Потім віддайте сценарій ШІ та вдосконаліть його за допомогою шаблону «harden» і зверніть увагу на 5 відмінностей між двома версіями.

контрольний список

  • [ ] Чи вказав я такі обмеження, як ОС, версія оболонки, шляхи та права у підказку?
  • [ ] Чи є сценарій відмовостійким із set -euo pipefail / $ErrorActionPreference='Stop'?
  • [ ] Чи є деструктивні операції за сухим запуском/-WhatIf і вимагають явного прапора перевірки?
  • [ ] Чи є сценарій ідемпотентним (безпечним під час другого запуску)?
  • [ ] Чи я витягнув секрети до змінної/секретного введення замість жорсткого кодування?
  • [ ] Чи я зробив перший запуск на тестовій машині та підготував план повернення?