Проекти наші зазвичай регіональні, і замовники зазвичай міністерства. Але крім держсектора нашими системами користуються і приватні організації. Із ними проблем практично немає.
Так от основні проекти — регіональні, а з ними часом бувають проблеми. Наприклад, з продуктивністю, коли в регіонах від 20 до наших дорогих користувачів у період викочування нового функціоналу на продуктові сервери. Це біль…
Звати мене Руслан і займаюся супроводом інформаційних систем «БАРС Груп» і розробкою бота-вбивці для жорстоких серійних DBA. Пост не для людей зі слабкими нервами — багато літер і картинок.
/awr
Деякі наші програми працюють на СУБД Oracle. Є проекти і на СУБД PostgreSQL. Oracle має чудову штуку — збір статистики навантаження на СУБД, яка підсвічує наявні проблеми і навіть дає рекомендації для усунення — Automatic Workload Repository (AWR). В один момент (а саме в момент болю) розробники постійно просили зібрати AWR-звіти для аналізу продуктивності. Ми чесно йшли на сервер СУБД, збирали звіти, тягли їх до себе та відправляли на аналіз у виробництво. Разу після 5-го це стало напружувати… після 10-го викликати роздратування…
Якось один із моїх колег висловив думку — все, що робиться більше одного разу, має бути автоматизовано. До моменту роздратування, якщо чесно, я про це не замислювався і намагався автоматизувати все, що можна автоматизувати, але часто це не було затребуване і мало швидше дослідницький, ніж прикладний характер.
І тут я подумав: «Не потрібні адміни для створення звіту…». Адже зібрати звіт - це виконати sql-скрипт @ $ ORACLE_HOME / rdbms / admin / awrrpt.sql і забрати звіт з сервера до себе ... Ах так, ми ж не пускаємо розробку на прод.
Тоді я нагуглив потрібну інформацію, створив на тестовій базі функцію зі статті, смикнув скрипт і диво - звіт зібрався і його можна зберегти локально. Створив функції там, де часто були потрібні AWR-звіти, розповів розробникам, як користуватися.
Приблизно в цей час на дозвіллі я, поспілкувавшись з @BotFather, створив собі телеграм-бота просто так, для розваги. Прикручував туди простенький функціонал — показати поточний час, курс валют, погоду, навчив його надсилати компліменти моїй дружині (тоді ще дівчині) за розкладом. Мабуть, на той момент відправка компліментів була найбільш потрібним функціоналом мого робота, дружина оцінила.
Так. Розробники пишуть нам у Телеграм, ми надсилаємо звіт їм у Телеграм… А що, якщо писати вони будуть не нам, а боту? Адже так усім буде краще, звіт буде отримано швидше, а найголовніше — повз нас. Так народилася ідея першого затребуваного функціоналу для мого робота.
Я розпочав реалізацію. Зробив, як зумів, на PHP (власне додаток наш на PHP, в ньому я більше розуміюся, ніж у тому ж Python). Кодер із мене так собі, тому свій код я не покажу 🙂
Бот живе в нашій корпоративній мережі, має доступ до певних проектів, у тому числі до цільових баз. Щоб не морочитися з параметрами в команді або меню, прикрутив цей функціонал до групового чату з повідомленнями моніторингу. Так бот одразу знає, на який БД збирати звіт.
Отримавши команду виду /awr Nде N - кількість повних годин, за які потрібен звіт (за замовчуванням - 1 година), хоч за тиждень, якщо БД не перезапускалася, бот негайно приступає до роботи, збирає звіт, публікує його у вигляді веб-сторінки і відразу (майже тут же) видає посилання так необхідний звіт.
Переходимо за посиланням і ось він, AWR-звіт:
Як і передбачалося, розробники впоралися з такою генерацією звітів, хтось навіть подякував.
Оцінивши зручність команди, таку ж захотіли керівники проектів з інших регіонів, тому що вони найбільше отримують люлів від замовника переживають за продуктивність та доступність систем. Додав робота і до інших чатів. Досі користуються, і я радий цьому.
Пізніше колеги з ЦИТ дізнались про те, як ми збираємо звіти, також захотіли. До наших чатів додавати їх не став, створив окремий чат з генерацією звітів за розкладом та за запитом.
/pgBadger
Є у нас і інші програми, на PHP у зв'язці з PostgreSQL. Реалізував збір звіту pgBadger для тих, хто потребує того ж принципу, — у групових чатах. Спершу користувалися, але потім перестали. Функціонал випиляв через непотрібність.
/duty
У нашому відділі є нічні чергування і, відповідно, є графік. Він знаходиться у гугл-таблицях. Не завжди зручно шукати посилання, відкривати графік, шукати себе… Один із колишніх колег теж грав зі своїм Телеграм-ботом та впровадив у чат нашого відділу повідомлення про початок чергової зміни для працівників відділу. Бот парсить графік, визначає чергового за поточною датою та, за розкладом чи за запитом, повідомляє, хто сьогодні черговий. Вийшло чудово, зручно. Щоправда, мені не дуже подобався формат повідомлень. Також для співробітників іншого відділу (наприклад, БЦ «Медицина») не дуже потрібна інформація про чергових в інших напрямках, але потрібно знати, хто є черговим у «Медицині» на випадок проблем. Вирішив "запозичити" функціонал, але змінити те, що мені не подобалося. Зробив зручний для себе та інших формат повідомлень, прибравши зайву інформацію.
/tnls
Після «проби пера» автоматизації за допомогою телеграм-бота з'явилося багато різних ідей, але хотілося робити потрібні речі. Вирішив вести статистику за зверненнями. Для доступу до проектів наших замовників у нас реалізовано так званий стрибковий сервер або сервер прокидів. На ньому піднімаються VPN-з'єднання, далі через ssh до нас в локальну мережу прокидаються порти додатків, БД та інші допоміжні прокиди, для зручності доступу до проектів наших співробітників, без проблем з VPN-підключеннями. Достатньо налаштувати VPN-підключення до нашої корпоративної мережі.
Статистика звернень підказала, що часто, після падіння якогось із тунелів (у разі мережевих проблем, з таймууту, наприклад), звертаються щодо відновлення доступу до проекту. Найчастіше досить просто перезапустити підключення і все стає добре. А давайте ви самі це робитимете. Ось і команда є:
«Провалюєшся» у потрібний пункт меню, вибираєш свій проект, чекаєш на хвилинку і всі щасливі та задоволені…
При отриманні команди, легким рухом руки байтів і бітів, робот підключається до сервера прокидів, заздалегідь знаючи, який прокидок потрібно перезапустити, і робить свою справу - відновлює підключення до проекту. Написав інструкцію, щоби самостійно вирішували подібні питання. А до нас зверталися лише у випадку, якщо цей інструмент не працює…
/ecp_to_pem
Далі статистика показала, що часто потрібно конвертувати ЕЦП Крипто Про в pem-формат() для різних інтеграцій, а їх у нас досить багато. Завдання: береш контейнер, копіюєш його на комп'ютер з Windows із встановленою утилітою P12FromGostCSP(до речі, платною), конвертуєш його в pfx, а вже pfx конвертуєш за допомогою OpenSSL(з підтримкою ГОСТового шифрування) в pem. Не дуже зручно, а хочеться по клацанню пальців.
Гугл знову прийшов на допомогу. Знайшов . Зібрав, як написано в README – запрацювало. Навчив робота працювати з утилітою і отримав практично моментальне конвертування.
На момент остаточної реалізації вийшов наказ про перехід на новий формат шифрування — gost-2012. Наскільки пам'ятаю, утиліта на той момент працювала лише зі старим ГОСТом (2001), можливо це була взагалі інша схожа утиліта іншої доброї людини, не пам'ятаю точно.
Після переходу на новий ДЕРЖСТАНДАРТ, функціонал у бота прибрав з міркувань безпеки. Реалізував його у docker-контейнері.
Dockerfile, раптом кому треба:
FROM ubuntu:16.04
RUN apt update && apt -y install git sudo wget unzip gcc g++ make &&
cd /srv/ && git clone https://github.com/kov-serg/get-cpcert.git &&
cd get-cpcert && chmod +x *.sh && ./prepare.sh && ./build.sh &&
mkdir -p /srv/{in,out} &&
echo '#!/bin/bash' > /srv/getpem.sh &&
echo 'cd /srv/get-cpcert' >> /srv/getpem.sh &&
echo './get-cpcert /srv/in/$CONT.000 $PASS > /srv/out/$CONT.pem' >> /srv/getpem.sh &&
chmod +x /srv/getpem.sh ENTRYPOINT /srv/getpem.shДля конвертації необхідно вихідний контейнер (директорія виду xxx.000) розмістити в директорії /srv/in, а забирати готовий pem у /srv/out.
Для конвертації виконати:
docker run -t -i -e CONT='<имя директории с контейнером(без ".000")>' -e PASS='<пароль для контейнера>' -v /srv/in:/srv/in -v /srv/out:/srv/out --name ecptopem <адрес нашего репозитория>/med/ecptopem:latest /emstop та /emstart
Одного разу в нашу фірму влаштувався дуже крутий Oracle DBA, з більшим досвідом в адмініструванні СУБД і в розробці. І відразу в нього не задалося з ssh-підключенням до серверів СУБД: то підключитися не знає куди і як, то доступи незрозуміло описані, то прокинути себе щось потрібне не виходить. Ну ми й раді допомогти, розповіли, як підключатися, прокинули для нього Enterprise Manager. А ось з ssh все одно не склалося. Один із колег пояснив це просто: DBA-чистокровка 🙂 Вирішили, якщо потрібно буде щось підкрутити на сервері, зробимо це самі.
EM буває падає під великим навантаженням, а перезапустити його… потрібно підключатися через ssh і перезапускати через термінал. "Адміни це добре вміють," - вирішив наш новий колега. Великі навантаження на СУБД у нас не рідкість, нерідкі сталі та прохання про перезапуск EM. Далі той самий сценарій: напруга, роздратування та пошук вирішення проблеми. Так у тих самих групових чатах з'явилися команди: /emstop та /emstart.
/вбити
У разі сильної конкуренції на базі, а таке іноді буває необхідно швидко розвантажити БД. Найшвидший спосіб – убити проблемний процес… Для цього підключаємося по ssh, kill-9… Бот допоможе!
Олексій оцінив команду і дав їй лагідну назву. «Кілялка» або рушниця.
Якось, подивившись, як Олексій намагається і страждає, вводячи щоразу /kill xxx для кожного з процесів, я вирішив додати «багатоствольності» нашій рушниці:
Так то краще! Все для тебе, Олексію, тільки працюй, любий!
Звичайно, до такої важливої команди був обмежений доступ по user_id - "захист від дурня". Побачивши, як Льоша вправно прибиває процеси на сервері БД, кілька людей спробували ввести команду з рандомним номером процесу, але мого розумного бота не обдуриш, він одразу відповів відмовою.
/alertlog
Ну і про всяк випадок, зробив команду:
/alertlog <у рядків> - Отримати вказану кількість рядків alertlog'a
Бот смикає alertlog і відправляє його на наш сервіс, типу pastebin, називається pyste, а в чат запиту відправляє посилання на пасту.
/checks
Далі надійшов запит на моніторинг реальної продуктивності нашої програми. Досі техпідтримка проекту руками збирала ці дані. Не діло! Наші доблесні тестувальники розробили тест-кейси для цього. Отримуваний лог тесту не дуже зручно читати, недосвідчений користувач довго розбиратиметься і не факт, що виділить потрібну інформацію. Та й ми не любимо робити руками те, що можна робити не руками… Нове завдання для робота!
Команда /checks видає нехитрое та недвозначне меню, цього разу наші хлопці навчилися користуватися цією командою без інструкції!
При виборі потрібного пункту, замість меню з'являється повідомлення про початок тесту, щоб нетерплячі користувачі не запускали 100500 XNUMX разів наш тест:
Залежно від вибраного пункту меню запускається певний тест з нашої мережі, а саме з машини, де живе бот (там попередньо налаштований jmeter, розміщені потрібні тести…) або одразу з ЦОДу (з підготовленої машини поруч із додатком), щоб при тестуванні виключити мережеві затримки, або звести їх до мінімуму.
Після завершення тесту та отримання лога, бот парсить його і видає результат у «чоловікочитаному» вигляді:
Збір метрик
Функціонал «зайшов» і охочі керівники проектів отримали таку функцію для своїх регіонів. А одна жаліслива Керівник проекту заявила: «Хочу мати статистику за часом!» Хтось із ЦІТ їй підказав, що було б зручно моніторити це все в Zabbix. Zabbix, так Zabbix…
Подумалося, що потрібно підготуватися до необхідності тиражування рішення. Оформив задум у docker-контейнер. У контейнері за розкладом (раз на 10 хвилин) запускається jmeter, складає лог в певному місці, php парсить його і видає потрібні дані у вигляді web-сторінки. Zabbix за допомогою ключа web.page.get отримує цю сторінку, регулярно вибирає потрібні дані для певних залежних елементів і будує графік.
Здається, вийшло непогано. Спостерігаючи графік, ми, по-перше, бачимо зразкову швидкість роботи програми, а у разі виявлення піків на графіці приблизно знаємо, де «затик». Все просто. Поки виявилося затребуваним лише для одного регіону, але я вже готовий розтиражувати для охочих.
Доопрацювання додатків
Статистика по однотипним завданням нещодавно підкинула ще ідеї для спрощення та полегшення праці. На деяких проектах, на серверах додатків є необхідність встановлювати ключові контейнери крипто Про, їх багато, і термін дії ЕЦП з часом закінчується. Іноді щодня «прилітає» по 2 завдання. Але використовувати бота для цього я вважав небезпечним і вирішив, що зроблю функціонал безпосередньо в додатку. Природно з авторизацією та перевіркою прав доступу. У разі наявності необхідних привілеїв буде доступний додатковий пункт меню для роботи з ЕЦП, установка, видалення, перегляд інформації та інше… На даний момент функціонал у процесі розробки. Як виявилося, це не дуже складно, потрібно злегка почитати існуючі інструкції, подивитися приклади коду, запитувати досвідченіших у розробці колег, та й робити. У процесі дослідження з'явилися ідеї для додавання додатку. Наполеонівських планів не буду будувати — є розробка, нехай кожен займається своєю справою. Але поки що цікаво — роблю сам.
Плани
Як я казав, народилося багато різних ідей використання нашого бота і не тільки — загалом, скажімо так, ідей для «точок автоматизації», багато хто з них забув, бо я не встиг їх записати. Тепер я намагаюся записувати все, що спадає на думку, і іншим рекомендую робити так само.
А ось Олексій не забуває підкидати свої хотіли. З останніх:
/kill_sql SQL_ID - вбити всі сесії з таким SQL_ID запитом
/kill_block — вбити корінну сесію, що блокує
/show_em - показати картинку продуктивності EM
Хитрун, хоче DBAшити з телефону =)
Ось так ми і працюємо на благо Батьківщини!
А як ви позбавляєте себе рутинних і нецікавих завдань?
Сподіваюся чтиво вийшло цікавим, а може навіть комусь корисним, і я не встиг втомити читача… Удачі всім нам.
Джерело: habr.com