Нашите проекти обикновено са регионални, а клиентите обикновено са министерства. Но освен публичния сектор, нашите системи използват и частни организации. Проблеми с тях практически няма.
Така че основните проекти са регионални и понякога има проблеми с тях. Например, с производителност, когато в регионите има повече от 20 XNUMX от нашите ценни потребители по време на периода на внедряване на нова функционалност на продуктовите сървъри. Това е болка…
Казвам се Руслан и поддържам информационните системи на БАРС Груп и разработване на убийствен бот за насилствени серийни DBA. Тази публикация не е за хора със слаби сърца - има много букви и снимки.
/awr
Някои от нашите приложения работят на Oracle DBMS. Има и проекти на СУБД PostgreSQL. Oracle има чудесно нещо - събиране на статистика за натоварването на СУБД, което подчертава съществуващите проблеми и дори дава препоръки за отстраняване - Automatic Workload Repository (AWR). В един момент (а именно в момента на болка) разработчиците постоянно поискаха да съберат AWR доклади за анализ на ефективността. Честно отидохме до сървъра на СУБД, събрахме отчети, занесохме ги при нас и ги изпратихме в производството за анализ. След 5-тия път стана досадно... след 10-тия - дразнещо...
Един мой колега веднъж изрази идеята, че всичко, което се прави повече от веднъж, трябва да бъде автоматизирано. До момента на раздразнение, честно казано, не мислех за това и се опитах да автоматизирам всичко, което можеше да бъде автоматизирано, но често не беше търсено и имаше по-скоро изследователски, отколкото приложен характер.
И тогава си помислих: „Не са необходими администратори за генериране на отчет...“. В края на краищата събирането на отчет означава изпълнение на sql скрипта @$ORACLE_HOME/rdbms/admin/awrrpt.sql и пренасяне на отчета от сървъра до вас... О, да, ние не позволяваме разработка за производство.
След това потърсих необходимата информация в Google, създадох функцията от статията в тестовата база, пуснах скрипта и чудо - отчетът беше компилиран и може да бъде записан локално. Създадени функции, при които AWR отчетите често са били необходими, и казано на разработчиците как да ги използват.
По това време, в свободното си време, след разговор с @BotFather, създадох бот на Telegram за себе си, просто за забавление. Прецаках проста функционалност там - показване на текущото време, валутни курсове, времето, научих го да изпраща комплименти на жена ми (тогава приятелка) по график. Може би по това време изпращането на комплименти беше най-популярната функционалност на моя бот и жена ми го оцени.
Така. Разработчиците ни пишат в Telegram, ние им изпращаме доклад в Telegram... Ами ако пишат не на нас, а на бот? В крайна сметка ще бъде по-добре за всички, докладът ще бъде получен по-бързо и най-важното, заобикаляйки нас. Така се роди идеята за първата популярна функционалност за моя бот.
Започнах изпълнението. Направих го, доколкото можах, на PHP (самото ни приложение е на PHP, аз съм по-запознат с него, отколкото с Python). Не съм добър програмист, така че няма да ви покажа моя код :)
Ботът живее в нашата корпоративна мрежа и има достъп до определени проекти, включително целеви бази данни. За да не се занимавам с параметри в екипа или менюто, добавих тази функционалност към груповия чат с известия за наблюдение. По този начин ботът веднага знае от коя база данни да събере отчета.
След като получи команда като /awr Н, където N е броят пълни часове, за които е необходим отчет (по подразбиране - 1 час), дори и за седмица, ако базата данни не е рестартирана, ботът веднага започва работа, събира отчета, публикува го като уеб страница и веднага (почти точно там) предоставя връзка към така необходимия доклад.
Следвайте връзката и ето го докладът на AWR:
Както се очакваше, разработчиците се справиха с такова генериране на отчети и някои дори ни благодариха.
След като оцениха удобството на екипа, ръководителите на проекти от други региони искаха същото, тъй като те получават най-много от клиента и се притесняват за производителността и наличността на системите. Добавих бота към други чатове. Все още го използват и се радвам за това.
По-късно колегите от CIT разбраха как събираме отчети и също пожелаха да го направят. Не ги добавих към нашите чатове, създадох отделен чат с генериране на отчети по график и по заявка.
/pgЯзовец
Имаме и други приложения в PHP във връзка с PostgreSQL. Приложих събирането на доклади от pgBadger за нуждаещите се на същия принцип - в групови чатове. Първо го използваха, но после спряха. Функционалността беше изрязана като ненужна.
/задължение
Нашият отдел е с нощни смени и съответно има график. Има го в Google Таблици. Не винаги е удобно да търсите линк, да отваряте диаграма, да търсите себе си... Един от моите бивши колеги също се заигра със своя Telegram бот и го въведе в чата на нашия отдел известия за започване на дежурната смяна за служителите на отдела. Ботът анализира графика, определя дежурния към текущата дата и според графика или при поискване съобщава кой е дежурен днес. Получи се страхотно и удобно. Вярно, не ми хареса много формата на съобщенията. Също така за служителите на друг отдел (например БЦ „Медицина“) информацията за дежурните в други посоки наистина не е необходима, но трябва да знаете кой е дежурен в „Медицина“ в случай на проблеми. Реших да „заема“ функционалността, но да променя това, което не ми харесва. Направих формат на съобщението, удобен за себе си и другите, като премахнах ненужната информация.
/tnls
След като изпробвах автоматизация с помощта на бот на Telegram, се появиха много различни идеи, но исках да правя строго необходими неща. Реших да водя статистика на заявките. За достъп до проектите на нашите клиенти сме внедрили така наречения „jump server“ или препращащ сървър. VPN връзките се повдигат на него, след което портовете на приложенията, базите данни и други спомагателни пренасочвания се препращат към нашата локална мрежа чрез ssh, за лесен достъп до проектите на нашите служители, без проблеми с VPN връзките. Всичко, което трябва да направите, е да настроите VPN връзка към нашата корпоративна мрежа.
Статистиката на заявките показва, че често, след като някой от тунелите се повреди (в случай на мрежови проблеми, поради изчакване, например), хората се свързват с нас за възстановяване на достъпа до проекта. В повечето случаи е достатъчно просто да рестартирате връзката и всичко е наред. Нека го направим сами. Ето командата:
„Попадате“ в желания елемент от менюто, избирате проекта си, изчаквате малко и всички са щастливи и доволни...
При получаване на команда, с леко движение на байтовете и битовете, ботът се свързва със сървъра за препращане, знаейки предварително кое препращане трябва да се рестартира и си върши работата - възстановява връзката към проекта. Написах инструкции, за да можете сами да решавате такива проблеми. И хората се свързваха с нас само ако предоставеният инструмент не работи...
/ecp_to_pem
Допълнителни статистики показват, че често е необходимо да се преобразува EDS Crypto Pro във формат pem() для различных интеграций, а их у нас достаточно много. Задача: берешь контейнер, копируешь его на компьютер с Windows с установленой утилитой P12FromGostCSP(к слову, платной), конвертируешь его в pfx, а уже pfx конвертируешь с помощью OpenSSL(c поддержкой ГОСТового шифрования) в pem. Не очень удобно, а хочется по щелчку пальцев.
Google отново се притече на помощ. Намерени . Сглобих го както е написано в README - стана. Научих бота да работи с помощната програма и получих почти мигновено преобразуване.
Към момента на окончателното внедряване беше издадена заповед за преминаване към нов формат за криптиране - gost-2012. Доколкото си спомням, помощната програма в този момент работеше само със стария GOST (2001), може би беше друга подобна програма от друг любезен човек, не помня точно.
След прехода към новия GOST функционалността на бота беше премахната от съображения за сигурност. Внедри го в докер контейнер.
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, убийте -9... Ботът ще помогне!
Алексей оцени екипа и му даде нежно име - "Килялка" или пистолет.
Един ден, след като гледах как Алексей се опитва и страда, въвеждайки /kill xxx всеки път за всеки от процесите, реших да добавя „многоцев“ към нашия пистолет:
Това е по-добре! Всичко е за теб, Алексей, само работа, скъпи!
Естествено, такъв важен екип беше ограничен достъп чрез user_id - „безупречен“. Виждайки как Леша умело убива процеси на сървъра на базата данни, няколко души се опитаха да въведат команда с произволен номер на процес, но не можете да заблудите моя интелигентен бот, той веднага отказа.
/alertlog
Е, за всеки случай направих командата:
/alertlog <брой редове> — вземете определения брой редове от alertlog
Ботът изтегля alertlog и го изпраща на нашата услуга, като pastebin, наречена pyste, и изпраща връзка към пастата към чата за заявки.
/проверки
След това дойде искане за наблюдение на реалната производителност на нашето приложение. Досега техническата поддръжка на проекта събираше тези данни ръчно. Без значение! Нашите доблестни тестери са разработили тестови случаи за това. Полученият тестов дневник не е много удобен за четене; неопитен потребител ще отнеме много време, за да разбере и не е сигурен, че ще подчертае необходимата информация. И не обичаме да правим с ръцете си това, което не можем да правим с ръцете си... Нова задача за бота!
Командата /checks показва просто и недвусмислено меню; този път нашите момчета се научиха как да използват тази команда без инструкции!
Когато изберете желания елемент, вместо меню се появява известие за началото на теста, така че нетърпеливите потребители да не изпълняват нашия тест 100500 XNUMX пъти:
В зависимост от избрания елемент от менюто, специфичен тест се стартира от нашата мрежа, а именно от машината, на която живее ботът (jmeter е предварително конфигуриран там, необходимите тестове са разположени...) или директно от центъра за данни (от подготвена машина до приложението), за да изключите мрежовите връзки при тестване на закъснения или да ги намалите до минимум.
След завършване на теста и получаване на дневника, ботът го анализира и извежда резултата в „четима за хора“ форма:
Колекция от метрики
Функционалността пристигна и заинтересованите ръководители на проекти получиха такава функция за своите региони. И един състрадателен ръководител на проекта каза: „Искам да имам статистика за времето!“ Някой от CIT й каза, че би било удобно да наблюдава всичко това в Zabbix. Zabbix, значи Zabbix...
Мислех, че трябва да се подготвя за необходимостта от копиране на решението... Поставих идеята в докер контейнер. В контейнера jmeter се стартира по график (веднъж на всеки 10 минути), поставя дневника на определено място, php го анализира и показва необходимите данни под формата на уеб страница. Zabbix, използвайки ключа web.page.get, получава тази страница, редовно избира необходимите данни за определени зависими елементи и изгражда графика.
Мисля, че не се получи лошо. Наблюдавайки графиката, ние първо виждаме приблизителната скорост на приложението и ако се открият пикове на графиката, ние знаем приблизително къде е „щепселът“. Просто е. Засега се оказа търсено само за един регион, но съм готов да го повторя за заинтересованите.
Разработка на приложения
Статистиката за подобни задачи напоследък породи повече идеи за опростяване и улесняване на работата. При някои проекти, на сървъри за приложения, има нужда от инсталиране на ключови Crypto Pro контейнери, има много от тях и цифровият подпис изтича с времето. Понякога пристигат 2 задачи на ден. Но сметнах, че не е безопасно да използвам бот за тези цели и реших, че ще създам функционалността директно в приложението. Естествено с авторизация и проверка на правата за достъп. Ако имате необходимите привилегии, ще бъде достъпен допълнителен елемент от менюто за работа с цифрови подписи, инсталиране, изтриване, преглед на информация и др. Функционалността в момента е в процес на разработка. Както се оказа, това не е много трудно, просто трябва да прочетете малко съществуващите инструкции, да разгледате примери за код, да попитате колеги, по-опитни в разработката, и след това да го направите. По време на процеса на проучване се появиха идеи за добавяне към приложението. Няма да правя наполеонови планове - има развитие, всеки да си гледа работата. Но въпреки че е интересно, аз го правя сам.
Планове
Както казах, много различни идеи се родиха за използването на нашия бот и не само - като цяло, да кажем, идеи за „точки за автоматизация“, много от тях бяха забравени, тъй като нямах време да ги запиша. Сега се опитвам да записвам всичко, което ми хрумне, и препоръчвам и на другите да направят същото.
Но Алексей не забравя да даде своите желания. От най-новото:
/kill_sql SQL_ID — убийте всички сесии с тази SQL_ID заявка
/kill_block - убийте сесията за блокиране на root
/покажи_ем — покажете снимка на ефективността на ЕМ
Той е хитрец, иска да шие DBA от телефона си =)
Така работим в полза на Родината!
Как се освобождавате от рутинните и безинтересни задачи?
Надявам се, че четивото се оказа интересно и може би дори полезно за някого и нямах време да отегчавам читателя... Успех на всички ни.
Източник: www.habr.com
