Hər kəsə salam, mənim adım Sergey Emelyanchik. Mən Audit-Telecom şirkətinin rəhbəriyəm, Veliam sisteminin əsas tərtibatçısı və müəllifiyəm. Dostumla necə autsorsing şirkəti yaratdığımız, özümüz üçün proqram təminatı yazdığımız və sonradan onu SaaS sistemi vasitəsilə hamıya yaymağa başladığımız haqqında məqalə yazmaq qərarına gəldim. Bunun mümkün olduğuna qəti şəkildə inanmadığım barədə. Məqalədə təkcə hekayə deyil, həm də Veliam məhsulunun necə yaradıldığına dair texniki detallar yer alacaq. Bəzi mənbə kodu parçaları daxil olmaqla. Hansı səhvləri etdiyimizi və onları necə düzəltdiyimizi daha sonra söyləyəcəyəm. Belə bir məqalənin dərc edilib-edilməməsinə şübhələr var idi. Amma düşündüm ki, məqaləni dərc etməməkdənsə, bunu etmək, rəy almaq və təkmilləşdirmək daha yaxşıdır...
Prehistorya
Bir şirkətdə İT işçisi kimi işləmişəm. Şirkət geniş şəbəkə strukturu ilə kifayət qədər böyük idi. Mən vəzifə öhdəliklərim üzərində dayanmayacağam, yalnız deyim ki, bunlara mütləq heç bir şeyin inkişafı daxil deyildi.
Monitorinqimiz var idi, amma sırf akademik maraqdan ötrü mən öz sadə birini yazmağa çalışmaq istədim. İdeya belə idi: mən onun internetdə olmasını istəyirdim ki, heç bir müştəri quraşdırmadan asanlıqla daxil ola bildim və hər hansı bir cihazdan, o cümlədən Wi-Fi vasitəsilə mobil cihazdan şəbəkə ilə nə baş verdiyini görə bildim və mən də həqiqətən Tez nə anlamaq istədim Otaqda “mopey” halına gələn avadanlıq var, çünki... bu kimi problemlərə cavab müddəti üçün çox ciddi tələblər var idi. Nəticədə beynimdə şəbəkə diaqramı ilə jpeg fonu olan sadə bir veb səhifə yazmaq, bu şəkildəki IP ünvanları ilə cihazların özlərini kəsmək və üzərində dinamik məzmun göstərmək planı yarandı. yaşıl və ya yanıb-sönən qırmızı IP ünvanı şəklində tələb olunan koordinatlarda şəkil. Tapşırıq qoyuldu, başlayaq.
Əvvəllər mən Delphi, PHP, JS və çox səthi olaraq C++ dillərində proqramlaşdırırdım. Mən şəbəkələrin necə işlədiyini yaxşı bilirəm. VLAN, Marşrutlaşdırma (OSPF, EIGRP, BGP), NAT. Bu, mənim özüm ibtidai monitorinq prototipini yazmağım üçün kifayət etdi.
PHP-də planlaşdırdıqlarımı yazdım. Apache və PHP serveri Windows-da idi, çünki... Linux mənim üçün o an anlaşılmaz və çox mürəkkəb bir şey idi, sonradan məlum oldu ki, mən çox yanılmışam və bir çox yerdə Linux Windows-dan daha sadədir, lakin bu ayrı bir mövzudur və hamımız bilirik ki, orada neçə holivar var. bu mövzu. Windows tapşırıq planlaşdırıcısı kiçik bir intervalla (dəqiq xatırlamıram, amma hər üç saniyədə bir dəfə) banal pinglə bütün obyektləri sorğulayan və vəziyyəti faylda saxlayan PHP skriptini çəkdi.
system(“ping -n 3 -w 100 {$ip_address}“);
Bəli, bəli, o an verilənlər bazası ilə işləmək də mənim üçün mənimsənilməmişdi. Prosesləri paralelləşdirməyin mümkün olduğunu bilmirdim və bütün şəbəkə qovşaqlarından keçmək çox vaxt apardı, çünki... bu bir mövzuda baş verdi. Problemlər xüsusilə bir neçə qovşaq mövcud olmadıqda ortaya çıxdı, çünki onların hər biri ssenarini 300 ms gecikdirdi. Müştəri tərəfində bir neçə saniyəlik fasilələrlə Ajax sorğusu ilə serverdən yenilənmiş məlumatı endirən və interfeysi yeniləyən sadə loop funksiyası var idi. Yaxşı, ard-arda 3 uğursuz pingdən sonra kompüterdə monitorinqi olan bir veb səhifə açılsa, şən bir kompozisiya oynadı.
Hər şey yoluna düşəndə mən nəticədən çox ruhlandım və düşündüm ki, ona daha çox əlavə edə bilərəm (biliyim və imkanlarım hesabına). Ancaq o vaxt düşündüyüm və bu günə qədər də düşündüyüm milyonlarla qrafikləri olan sistemləri həmişə bəyənməmişəm, əksər hallarda lazımsızdır. Mən ora yalnız işimə həqiqətən kömək edəcək şeyi qoymaq istədim. Bu prinsip bu günə qədər Veliamın inkişafı üçün əsas olaraq qalır. Bundan əlavə, başa düşdüm ki, monitorinqi açıq saxlamaq və problemlər barədə məlumatlı olmaq lazım olmasaydı və bu baş verəndə səhifəni açın və bu problemli şəbəkə nodeunun harada yerləşdiyini və bundan sonra onunla nə edəcəyini görün. . Nədənsə o vaxtlar e-poçtu oxumurdum, sadəcə istifadə etmirdim. İnternetdə rast gəldim ki, GET və ya POST sorğusu göndərə biləcəyiniz SMS şlüzləri var və mənim mobil telefonuma yazdığım mətnlə SMS göndərəcəklər. Dərhal başa düşdüm ki, mən bunu çox istəyirəm. Və sənədləri öyrənməyə başladım. Bir müddət sonra bacardım və indi mobil telefonuma “düşmüş obyekt” adı ilə şəbəkədəki problemlər barədə SMS gəldi. Sistem primitiv olsa da, onu özüm yazmışdım və onu inkişaf etdirməyə məni motivasiya edən ən əsası işimdə həqiqətən mənə kömək edən tətbiq proqramı olması idi.
Və sonra gün gəldi ki, internet kanallarından biri iş yerində dayandı və monitorinqim bu barədə mənə məlumat vermədi. Google DNS hələ də mükəmməl şəkildə pingləndiyindən. Rabitə kanalının canlı olduğunu necə izləyə biləcəyinizi düşünməyin vaxtı gəldi. Bunu necə etmək barədə müxtəlif fikirlər var idi. Bütün avadanlıqlara çıxışım yox idi. Kanallardan hansının canlı olduğunu necə başa düşmək lazım olduğunu anlamalı olduq, ancaq şəbəkə avadanlığının özündə bir şəkildə baxa bilmədik. Sonra bir həmkarı belə bir fikir irəli sürdü ki, ictimai serverlərə marşrutun izlənilməsi hazırda İnternetə daxil olmaq üçün hansı rabitə kanalından istifadə olunduğundan asılı olaraq fərqli ola bilər. Yoxladım və belə çıxdı. İzləmə zamanı müxtəlif marşrutlar var idi.
system(“tracert -d -w 500 8.8.8.8”);
Beləliklə, başqa bir skript meydana çıxdı, daha doğrusu, nədənsə şəbəkədəki bütün cihazları ping edən eyni skriptin sonuna iz əlavə edildi. Axı, bu, eyni mövzuda icra edilən və bütün skriptin işini yavaşlatan başqa bir uzun prosesdir. Amma sonra bu o qədər də aydın deyildi. Ancaq bu və ya digər şəkildə, o, öz işini gördü, kod kanalların hər biri üçün hansı növ izləmənin olmasını ciddi şəkildə müəyyənləşdirdi. Sistem belə işləməyə başladı, hansı ki, artıq monitorinq aparan (yüksək səslə, çünki heç bir metrik toplusu yox idi, sadəcə olaraq, ping) şəbəkə cihazlarını (marşrutlaşdırıcılar, açarlar, wi-fi və s.) və xarici dünya ilə əlaqə kanallarını izləyirdi. . SMS mesajları müntəzəm olaraq gəlirdi və diaqram həmişə problemin harada olduğunu aydın şəkildə göstərirdi.
Bundan əlavə, gündəlik işdə çarpaz keçid etməli oldum. Hansı interfeysdən istifadə edəcəyimi görmək üçün hər dəfə Cisco keçidlərinə getməkdən yoruldum. Monitorinq zamanı obyektin üzərinə klikləmək və onun interfeyslərinin təsviri ilə siyahısını görmək necə də gözəl olardı. Bu, mənim vaxtıma qənaət edəcəkdi. Üstəlik, bu sxemdə hesabları və əmrləri daxil etmək üçün Putty və ya SecureCRT-ni işə salmağa ehtiyac qalmayacaq. Sadəcə monitorinqin üzərinə klik etdim, nə lazım olduğunu gördüm və öz işimi görmək üçün getdim. Mən açarlarla əlaqə qurmağın yollarını axtarmağa başladım. Dərhal 2 variantla qarşılaşdım: SNMP və ya SSH vasitəsilə keçidə daxil olmaq, mənə lazım olan əmrləri daxil etmək və nəticəni təhlil etmək. Tətbiqinin mürəkkəbliyinə görə SNMP-ni işdən çıxartdım, nəticə əldə etmək üçün səbirsiz idim. SNMP ilə siz uzun müddət MIB-də qazılmalı və bu məlumatlara əsaslanaraq interfeyslər haqqında məlumat yaratmalı olacaqsınız. CISCO-da gözəl komanda var
show interface statusBu, çarpaz keçidlər üçün nəyə ehtiyacım olduğunu dəqiq göstərir. Mən sadəcə bu əmrin çıxışını görmək istədiyim zaman SNMP ilə niyə narahatam ki, düşündüm. Bir müddət sonra bu fürsəti dərk etdim. Veb səhifədəki obyektə kliklədi. AJAX müştərisinin serverlə əlaqə saxladığı bir hadisə baş verdi və o, öz növbəsində SSH vasitəsilə mənə lazım olan keçidə qoşuldu (etimadnamələr koda kodlaşdırılmışdı, onu dəqiqləşdirmək, bəzi ayrı menyular etmək istəyi yox idi). interfeysdən hesabları dəyişmək olardı , mənə nəticə lazım idi və tez) yuxarıdakı əmri orda daxil etdim və yenidən brauzerə göndərdim. Beləliklə, bir siçan ilə interfeyslər haqqında məlumat görməyə başladım. Bu, çox rahat idi, xüsusən də bu məlumatı eyni anda müxtəlif açarlarda görmək lazım olduqda.
İz əsaslı kanal monitorinqi ən yaxşı fikir olmadı, çünki... bəzən şəbəkədə iş aparılırdı və izləmə dəyişə bilirdi və monitorinq kanalda problemlər olduğunu mənə qışqırmağa başladı. Amma təhlillərə çox vaxt sərf etdikdən sonra başa düşdüm ki, bütün kanallar işləyir, monitorinqim məni aldadır. Nəticə olaraq, mən kanal yaratma açarlarını idarə edən həmkarlarımdan qonşuların görünmə statusu dəyişdikdə sadəcə mənə syslog göndərmələrini xahiş etdim. Müvafiq olaraq, izləməkdən daha sadə, daha sürətli və daha dəqiq idi. İtmiş qonşu kimi bir hadisə gəldi və mən dərhal kanalın aşağı olması barədə bildiriş verirəm.
Bundan əlavə, bir obyektə kliklədikdə daha bir neçə əmr ortaya çıxdı və bəzi ölçüləri toplamaq üçün SNMP əlavə edildi və bu, əsasən budur. Sistem heç vaxt daha inkişaf etmədi. Mənə lazım olan hər şeyi etdi, yaxşı alət idi. Yəqin ki, bir çox oxucu mənə deyəcək ki, bu problemləri həll etmək üçün İnternetdə artıq çoxlu proqram təminatı mövcuddur. Amma əslində, mən o zaman belə pulsuz məhsulları google-də axtarmırdım və həqiqətən proqramlaşdırma bacarıqlarımı inkişaf etdirmək istəyirdim və bunun üçün real tətbiq problemindən daha yaxşı hansı yol var. Bu nöqtədə monitorinqin ilk versiyası tamamlandı və artıq dəyişdirilmədi.
Audit-Telecom şirkətinin yaradılması
Vaxt keçdikcə başqa şirkətlərdə part-time işləməyə başladım, xoşbəxtlikdən iş qrafikim bunu etməyə imkan verdi. Müxtəlif şirkətlərdə işlədiyiniz zaman müxtəlif sahələrdə bacarıqlarınız çox sürətlə inkişaf edir və üfüqləriniz yaxşı inkişaf edir. Elə şirkətlər var ki, orada necə deyərlər, isveçlisən, biçinçisən, zurna çalansan. Bir tərəfdən çətindir, digər tərəfdən, tənbəl deyilsinizsə, ümumi mütəxəssis olursunuz və bu, problemləri daha sürətli və daha səmərəli həll etməyə imkan verir, çünki əlaqəli sahənin necə işlədiyini bilirsiniz.
Dostum Pavel (həmçinin İT mütəxəssisi) daim məni öz biznesini qurmağa təşviq etməyə çalışırdı. Onların etdiklərinin müxtəlif varyasyonları olan saysız-hesabsız fikirlər var idi. Bu, illərdir müzakirə olunur. Və sonda heç nəyə gəlməməli idi, çünki mən skeptikəm, Pavel isə xəyalpərəstdir. Hər dəfə o, ideya təklif edəndə mən həmişə buna inanmamışam və iştirak etməkdən imtina etmişəm. Amma biz öz biznesimizi açmaq istəyirdik.
Nəhayət, hər ikimizə uyğun olan variantı tapa bildik və bildiyimizi edə bildik. 2016-cı ildə biz müəssisələrə İT problemlərini həll etməyə kömək edəcək İT şirkəti yaratmağa qərar verdik. Bu, İT sistemlərinin (1C, terminal serveri, poçt serveri və s.) yerləşdirilməsi, onlara texniki qulluq, istifadəçilər üçün klassik HelpDesk və şəbəkə administrasiyasıdır.
Açığını deyim ki, şirkəti yaradanda mən buna 99,9% inanmırdım. Amma nədənsə Pavel məni sınamağa vadar edə bildi və irəliyə baxanda o, haqlı çıxdı. Pavel və mən hər birinə 300 rubl pul yığdıq, yeni "Audit-Telecom" MMC-ni qeydiyyata aldıq, kiçik bir ofis icarəyə götürdük, ümumiyyətlə, ən təcrübəsiz, təcrübəsiz iş adamları kimi sərin vizit kartları hazırladıq və müştərilər axtarmağa başladıq. Müştəri tapmaq tamam başqa bir hekayədir. Ola bilsin ki, hər kəs maraqlanırsa, korporativ bloqun bir hissəsi kimi ayrıca məqalə yazacağıq. Soyuq zənglər, flayerlər və s. Bu heç bir nəticə vermədi. İndi bizneslə bağlı bir çox hekayələrdən oxuduğum kimi, bu və ya digər şəkildə, çox şey şansdan asılıdır. Bəxtimiz gətirdi. və sözün əsl mənasında, şirkətin yaradılmasından bir neçə həftə sonra qardaşım Vladimir bizə yaxınlaşdı, o, bizə ilk müştərimizi gətirdi. Müştərilərlə işləməyin təfərrüatları ilə sizi bezdirməyəcəm, məqalənin mövzusu bu deyil, sadəcə olaraq onu deyim ki, biz auditə getdik, kritik sahələr müəyyənləşdirdik və bu sahələr xarab olub-olmaması ilə bağlı qərar verilərkən autsorser kimi bizimlə davamlı əməkdaşlıq edin. Bundan sonra dərhal müsbət qərar verildi.
Sonra, əsasən, dostlar vasitəsilə ağızdan-ağıza başqa xidmət şirkətləri meydana çıxmağa başladı. Yardım masası bir sistemdə idi. Şəbəkə avadanlığı və serverlərinə qoşulmalar fərqlidir, daha doğrusu fərqlidir. Bəzi insanlar qısa yolları saxladı, digərləri RDP ünvan kitablarından istifadə etdi. Monitorinq başqa bir ayrı sistemdir. Komandanın fərqli sistemlərdə işləməsi çox əlverişsizdir. Vacib məlumatlar gözdən itdi. Məsələn, müştərinin terminal serveri əlçatmaz oldu. Bu müştərinin istifadəçilərinin müraciətləri dərhal qəbul edilir. Dəstək mütəxəssisi sorğu açır (telefonla qəbul edilib). Əgər insidentlər və sorğular bir sistemdə qeydə alınsaydı, o zaman dəstək mütəxəssisi dərhal istifadəçinin probleminin nə olduğunu görər və ona bu barədə məlumat verər, eyni zamanda vəziyyəti işləmək üçün tələb olunan obyektə qoşulur. Hər kəs taktiki vəziyyətdən xəbərdardır və ahənglə işləyir. Bütün bunların birləşdirildiyi sistem tapmamışıq. Məlum oldu ki, öz məhsulumuzu hazırlamağın vaxtı çatıb.
Monitorinq sisteminizdə davam edən işlər
Aydın idi ki, əvvəllər yazılmış sistem hazırkı vəzifələr üçün tamamilə yararsızdır. Nə funksionallıq baxımından, nə də keyfiyyət baxımından. Və sistemin sıfırdan yazılması qərara alındı. Qrafik olaraq tamamilə fərqli görünməli idi. O, iyerarxik sistem olmalı idi ki, lazımi müştəri üçün lazımi obyekti tez və rahat şəkildə açmaq mümkün olsun. Birinci versiyada olduğu kimi sxem indiki halda qətiyyən özünü doğrultmadı, çünki Müştərilər fərqlidir və avadanlığın hansı binada yerləşməsinin heç bir əhəmiyyəti yox idi. Bu artıq sənədləşməyə keçib.
Beləliklə, vəzifələr:
- iyerarxik quruluş;
- Lazım olan ölçüləri toplamaq və bütün bunları ümumiləşdirəcək və bizə göstərəcək mərkəzi serverə göndərmək üçün virtual maşın şəklində müştərinin binasına yerləşdirilə bilən bir növ server hissəsi;
- Xəbərdarlıqlar. Bunları qaçırmaq olmaz, çünki... o zaman kiminsə oturub sadəcə monitora baxması mümkün deyildi;
- Tətbiq sistemi. Yalnız server və şəbəkə avadanlıqlarına deyil, həm də iş stansiyalarına xidmət göstərdiyimiz müştərilər peyda olmağa başladı;
- Sistemdən serverlərə və avadanlıqlara sürətli qoşulma bacarığı;
Tapşırıqlar qoyuldu, yazmağa başlayırıq. Yolda müştərilərdən gələn sorğuların işlənməsi. O vaxt artıq 4 nəfər idik. Biz bir anda hər iki hissəni yazmağa başladıq: mərkəzi server və müştərilərə quraşdırma üçün server. Bu nöqtədə, Linux artıq bizə yad deyildi və müştərilərin sahib olacağı virtual maşınların Debian-da olacağına qərar verildi. Quraşdırıcılar olmayacaq, biz sadəcə bir xüsusi virtual maşında server hissəsi layihəsi edəcəyik və sonra onu istədiyiniz müştəriyə klonlayacağıq. Bu başqa bir səhv idi. Sonradan məlum oldu ki, belə bir sxemdə yeniləmə mexanizmi tamamilə inkişaf etdirilməmişdir. Bunlar. biz bəzi yeni funksiyalar əlavə edirdik və sonra onu bütün müştəri serverlərinə paylamaq problemi var idi, lakin biz buna daha sonra qayıdacağıq, hər şey qaydasında.
İlk prototipi hazırladıq. O, bizə lazım olan müştəri şəbəkə cihazlarına və serverlərinə ping göndərə və bu məlumatları mərkəzi serverimizə göndərə bildi. Və o, öz növbəsində, mərkəzi serverdə bu məlumatları toplu olaraq yeniləyirdi. Burada mən təkcə necə və nəyin uğurlu olduğu haqqında hekayə yazacam, həm də hansı həvəskar səhvlərə yol verilib və sonradan bunun əvəzini zamanla ödəməli oldum. Beləliklə, bütün obyektlər ağacı seriallaşdırılmış obyekt şəklində bir faylda saxlanıldı. Bir neçə müştərini sistemə bağladığımız zaman hər şey az-çox normal idi, baxmayaraq ki, bəzən tamamilə anlaşılmaz olan bəzi artefaktlar da olurdu. Amma sistemə onlarla server qoşduqda möcüzələr baş verməyə başladı. Bəzən naməlum səbəblərdən sistemdəki bütün obyektlər sadəcə yox olur. Burada qeyd etmək lazımdır ki, müştərilər POST sorğusu vasitəsilə bir neçə saniyədən bir mərkəzi serverə məlumat göndərmiş serverlər. Diqqətli oxucu və təcrübəli proqramçı artıq təxmin etdi ki, seriallaşdırılmış obyektin eyni anda müxtəlif mövzulardan saxlandığı fayla çoxsaylı giriş problemi var. Və məhz bu baş verəndə cisimlərin yox olması ilə möcüzələr baş verdi. Fayl sadəcə boş oldu. Ancaq bütün bunlar dərhal deyil, yalnız bir neçə serverlə əməliyyat zamanı aşkar edildi. Bu müddət ərzində portun skan edilməsi funksiyası əlavə edildi (serverlər mərkəzə təkcə cihazların mövcudluğu haqqında deyil, həm də onlarda açılan portlar haqqında məlumat göndərilir). Bu əmri çağırmaqla edildi:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
nəticələr çox vaxt səhv olurdu və skanların tamamlanması uzun vaxt apardı. Pinqi tamamilə unutmuşam, bu fping vasitəsilə edilib:
system("fping -r 3 -t 100 {$this->ip}");
Bu da paralelləşdirilmədi və ona görə də proses çox uzun idi. Daha sonra yoxlama üçün tələb olunan IP ünvanlarının bütün siyahısı bir anda fping-ə göndərildi və geriyə cavab verənlərin hazır siyahısını aldıq. Bizdən fərqli olaraq fping prosesləri paralelləşdirə bildi.
Başqa bir ümumi iş WEB vasitəsilə bəzi xidmətlərin qurulması idi. Yaxşı, məsələn, MS Exchange-dən ECP. Əsasən bu, sadəcə bir keçiddir. Və qərara gəldik ki, müəyyən bir müştərinin ECP-yə necə daxil olmaq üçün sənədlərə və ya əlfəcinlərdə başqa yerə baxmaq məcburiyyətində qalmamaq üçün bu cür bağlantıları birbaşa sistemə əlavə edə bilməliyik. Sistem üçün resurs əlaqələri konsepsiyası belə ortaya çıxdı, onların funksionallığı bu günə qədər mövcuddur və demək olar ki, dəyişməyib.
Resurs bağlantıları Veliam-da necə işləyir
Uzaqdan bağlantılar
Veliamın hazırkı versiyasında bu, hərəkətdə olduğu kimi görünür
Tapşırıqlardan biri serverlərə tez və rahat şəkildə qoşulmaq idi, onlardan çoxu (yüzdən çox) və milyonlarla əvvəlcədən saxlanmış RDP qısa yolları arasında çeşidləmək olduqca əlverişsiz idi. Alət lazımdı. İnternetdə belə RDP əlaqələri üçün ünvan kitabçası kimi bir proqram var, lakin onlar monitorinq sistemi ilə inteqrasiya olunmayıb və hesabları saxlamaq mümkün deyil. Gündə onlarla dəfə müxtəlif serverlərə qoşulduqda hər dəfə fərqli müştərilər üçün hesablara girmək cəhənnəmdir. SSH ilə işlər bir az daha yaxşıdır; bu cür əlaqələri qovluqlarda təşkil etməyə və onlardan hesabları yadda saxlamağa imkan verən çoxlu yaxşı proqramlar var. Amma 2 problem var. Birincisi, RDP və SSH əlaqələri üçün bir proqram tapmamağımızdır. İkincisi, əgər bir anda kompüterimdə deyiləmsə və tez qoşulmalıyamsa və ya sistemi sadəcə yenidən quraşdırmışamsa, bu müştəridən hesaba baxmaq üçün sənədlərə daxil olmalıyam. Bu, əlverişsizdir və vaxt itkisidir.
Müştəri serverləri üçün lazım olan iyerarxik quruluş artıq daxili məhsulumuzda mövcud idi. Mən sadəcə orada lazımi avadanlıqlara sürətli bağlantıları necə bağlayacağımı anlamalı idim. Başlayanlar üçün, ən azı şəbəkəniz daxilində.
Sistemimizdəki müştərinin kompüterin yerli resurslarına çıxışı olmayan bir brauzer olduğunu nəzərə alaraq, bizə lazım olan proqramı sadəcə hansısa əmrlə işə salmaq üçün hər şeyi “Windows” vasitəsilə etmək icad edilmişdir. fərdi url sxemi”. Sistemimiz üçün sadəcə Putty və Remote Desktop Plus daxil olan və quraşdırma zamanı sadəcə Windows-da URI sxemini qeydiyyatdan keçirən müəyyən bir "plugin" belə ortaya çıxdı. İndi RDP və ya SSH vasitəsilə obyektə qoşulmaq istədikdə sistemimizdə bu əməliyyatı klik etdik və Xüsusi URI işlədi. “Plugin”in bir hissəsi olan Windows və ya şkafda quraşdırılmış standart mstsc.exe işə salındı. Plugin sözünü dırnaq içərisində qoydum, çünki bu, klassik mənada brauzer plagini deyil.
Ən azından bu bir şey idi. Rahat ünvan kitabçası. Üstəlik, Putty vəziyyətində hər şey ümumiyyətlə yaxşı idi, ona giriş parametrləri kimi IP əlaqələri, giriş və şifrə verilə bilər. Bunlar. Biz artıq şəbəkəmizdəki Linux serverlərinə parol daxil etmədən bir kliklə qoşulmuşuq. Ancaq RDP ilə bu o qədər də sadə deyil. Standart mstsc etimadnamələri parametr kimi təmin edə bilməz. Remote Desktop Plus köməyə gəldi. Bunun baş verməsinə icazə verdi. İndi biz onsuz edə bilərik, lakin uzun müddət sistemimizdə sadiq köməkçi idi. HTTP(S) saytlarında hər şey sadədir, belə obyektlər sadəcə olaraq brauzerdə açılır və belədir. Rahat və praktikdir. Ancaq bu, yalnız daxili şəbəkədə xoşbəxtlik idi.
Problemlərin böyük əksəriyyətini ofisdən uzaqdan həll etdiyimiz üçün ən asanı VPN-ləri müştərilər üçün əlçatan etmək idi. Və sonra bizim sistemdən onlara qoşulmaq mümkün oldu. Amma yenə də bir qədər əlverişsiz idi. Hər bir müştəri üçün hər bir kompüterdə yadda qalan VPN bağlantılarını saxlamaq lazım idi və hər hansı birinə qoşulmazdan əvvəl müvafiq VPN-i işə salmaq lazım idi. Bu həlli kifayət qədər uzun müddət istifadə etdik. Ancaq müştərilərin sayı artır, VPN-lərin sayı da artır və bütün bunlar gərginləşməyə başladı və bununla bağlı nəsə etmək lazım idi. Xüsusilə sistemi yenidən quraşdırdıqdan sonra, yeni Windows profilində onlarla VPN bağlantısını yenidən daxil etməli olduğum zaman gözlərim yaşardı. Buna dözmə, dedim və bununla bağlı nə edə biləcəyimi düşünməyə başladım.
Belə oldu ki, bütün müştərilərin marşrutlaşdırıcıları kimi tanınmış Mikrotik şirkətinin cihazları var idi. Onlar çox funksionaldır və demək olar ki, hər hansı bir işi yerinə yetirmək üçün əlverişlidir. İşin mənfi tərəfi onların “qaçırılması”dır. Sadəcə olaraq kənardan bütün girişləri bağlamaqla bu problemi həll etdik. Ancaq müştərinin yerinə gəlmədən onlara birtəhər daxil olmaq lazım idi, çünki... uzundur. Biz sadəcə olaraq hər bir belə Mikrotik üçün tunellər düzəltdik və onları ayrıca hovuza ayırdıq. heç bir marşrutlaşdırma olmadan, beləliklə, şəbəkənizin müştərilərin şəbəkələri və bir-biri ilə şəbəkələri ilə əlaqəsi yoxdur.
İdeya odur ki, sistemdə mənə lazım olan obyektin üzərinə kliklədiyim zaman mərkəzi monitorinq serveri bütün Mikrotik müştərisinin SSH hesablarını bilərək, istədiyiniz birinə qoşulur, istədiyiniz hosta yönləndirmə qaydası yaradır. tələb olunan port. Burada bir neçə məqam var. Həll universal deyil - yalnız Mikrotik üçün işləyəcək, çünki əmr sintaksisi bütün marşrutlaşdırıcılar üçün fərqlidir. Bundan əlavə, bu cür yönləndirmələr bir şəkildə silinməli idi və sistemimizin server hissəsi mənim RDP sessiyamı bitirdiyimi heç bir şəkildə izləyə bilmədi. Yaxşı, belə bir yönləndirmə müştəri üçün bir boşluqdur. Amma biz universallığın arxasınca getmədik, çünki... məhsul yalnız bizim şirkət daxilində istifadə olunub və onu ictimaiyyətə təqdim etmək fikri yox idi.
Problemlərin hər biri özünəməxsus şəkildə həll edildi. Qayda yaradıldıqda, bu yönləndirmə yalnız bir xüsusi xarici IP ünvanı (bağlantı başlatıldığı üçün) üçün mövcud idi. Beləliklə, təhlükəsizlik çuxurunun qarşısı alındı. Ancaq hər bir belə əlaqə ilə NAT səhifəsinə Mikrotik qaydası əlavə edildi və silinmədi. Və hər kəs bilir ki, qaydalar nə qədər çox olarsa, marşrutlaşdırıcının prosessoru bir o qədər çox yüklənir. Və ümumiyyətlə, qəbul edə bilməzdim ki, bir gün hansısa Mikrotikə gedəcəyəm və orada yüzlərlə ölü, yararsız qaydalar olacaq.
Serverimiz əlaqə vəziyyətini izləyə bilmədiyi üçün Mikrotik onları özü izləsin. Mən bütün yönləndirmə qaydalarını müəyyən bir təsvirlə daim izləyən və TCP bağlantısının uyğun bir qaydanın olub olmadığını yoxlayan bir skript yazdım. Bir müddətdir biri yoxdursa, o zaman əlaqə artıq tamamlanıb və bu yönləndirmə silinə bilər. Hər şey alındı, ssenari yaxşı işlədi.
Yeri gəlmişkən, budur:
global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={
local dstport [/ip firewall nat get value-name="dst-port" $i]
local dstaddress [/ip firewall nat get value-name="dst-address" $i]
local dstaddrport "$dstaddress:$dstport"
#log warning message=$dstaddrport
local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
if ($thereIsCon = "") do={
set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
#:log warning message=($atmonrulecounter->$dstport)
if (($atmonrulecounter->$dstport) > 5) do={
#log warning message="Removing nat rules added automaticaly by atmon_script"
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
set ($atmonrulecounter->$dstport) 0
}
} else {
set ($atmonrulecounter->$dstport) 0
}
}
Şübhəsiz ki, daha gözəl, daha sürətli və s. etmək olardı, amma işlədi, Mikrotiki yükləmədi və əla iş gördü. Biz nəhayət bir kliklə müştərilərin serverlərinə və şəbəkə avadanlıqlarına qoşula bildik. VPN açmadan və ya parol daxil etmədən. Sistem işləmək üçün həqiqətən əlverişli hala gəldi. Xidmət müddəti azaldı və biz hamımız lazımi obyektlərə qoşulmaqdansa, işləməyə vaxt sərf etdik.
Mikrotik Yedəkləmə
Biz bütün Mikrotikin ehtiyat nüsxəsini FTP-yə konfiqurasiya etdik. Və ümumilikdə hər şey yaxşı idi. Ancaq ehtiyat nüsxəsini əldə etmək lazım olduqda, bu FTP-ni açmalı və orada axtarmalı idiniz. Bütün marşrutlaşdırıcıların qoşulduğu bir sistemimiz var, biz SSH vasitəsilə cihazlarla əlaqə saxlaya bilərik. Niyə elə etmirik ki, sistemin özü gündəlik bütün Mikrotik-dən ehtiyat nüsxələri götürsün, düşündüm. Və onu həyata keçirməyə başladı. Qoşulduq, ehtiyat nüsxəsini çıxardıq və yaddaşa apardıq.
Mikrotikdən ehtiyat nüsxə çıxarmaq üçün PHP-də skript kodu:
<?php
$IP = '0.0.0.0';
$LOGIN = 'admin';
$PASSWORD = '';
$BACKUP_NAME = 'test';
$connection = ssh2_connect($IP, 22);
if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;
ssh2_exec($connection, '/system backup save name="atmon" password="atmon"');
stream_get_contents($connection);
ssh2_exec($connection, '/export file="atmon.rsc"');
stream_get_contents($connection);
sleep(40); // Waiting bakup makes
$sftp = ssh2_sftp($connection);
// Download backup file
$size = filesize("ssh2.sftp://$sftp/atmon.backup");
$stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read < $len && ($buf = fread($stream, $len - $read))) {
$read += strlen($buf);
$contents .= $buf;
}
file_put_contents ($BACKUP_NAME . ‘.backup’,$contents);
@fclose($stream);
sleep(3);
// Download RSC file
$size = filesize("ssh2.sftp://$sftp/atmon.rsc");
$stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read < $len && ($buf = fread($stream, $len - $read))) {
$read += strlen($buf);
$contents .= $buf;
}
file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
@fclose($stream);
ssh2_exec($connection, '/file remove atmon.backup');
ssh2_exec($connection, '/file remove atmon.rsc');
?>
Yedək iki formada alınır - ikili və mətn konfiqurasiyası. Binar tələb olunan konfiqurasiyanı tez bir zamanda bərpa etməyə kömək edir və bir mətn, avadanlığın məcburi dəyişdirilməsi halında nə edilməli olduğunu başa düşməyə imkan verir və binar ona yüklənə bilmir. Nəticədə sistemdə daha bir rahat funksionallıq əldə etdik. Üstəlik, yeni Mikrotik əlavə edərkən heç bir şey konfiqurasiya etməyə ehtiyac yox idi, sadəcə olaraq obyekti sistemə əlavə etdim və SSH vasitəsilə onun üçün hesab yaratdım. Sonra sistem özü ehtiyat nüsxələrinin alınması ilə məşğul oldu. SaaS Veliam-ın cari versiyasında bu funksiya hələ yoxdur, lakin biz onu tezliklə portla edəcəyik.
Daxili sistemdə necə göründüyünün skrinşotları
Normal verilənlər bazası yaddaşına keçid
Artefaktların meydana çıxdığını yuxarıda yazdım. Bəzən sistemdəki obyektlərin bütün siyahısı sadəcə olaraq yoxa çıxır, bəzən obyekti redaktə edərkən məlumat saxlanmır və obyektin adını üç dəfə dəyişdirmək lazım gəlirdi. Bu, hamını dəhşətli dərəcədə qıcıqlandırdı. Obyektlərin yoxa çıxması nadir hallarda baş verirdi və bu faylı bərpa etməklə asanlıqla bərpa olunurdu, lakin obyektləri redaktə edərkən uğursuzluqlar olduqca tez-tez baş verirdi. Yəqin ki, mən əvvəlcə bunu verilənlər bazası vasitəsilə etmədim, çünki düz bir masada bütün əlaqələri olan bir ağacı necə saxlamaq mümkün olduğu fikrimə uyğun gəlmirdi. Düzdür, lakin ağac iyerarxikdir. Lakin çoxlu giriş və sonradan (sistem mürəkkəbləşdikcə) əməliyyat üçün yaxşı bir həll DBMS-dir. Yəqin ki, bu problemlə ilk qarşılaşan mən deyiləm. Mən axtarışa başladım. Məlum oldu ki, hər şey məndən əvvəl icad edilmişdir və düz masadan ağac quran bir neçə alqoritm var. Hər birinə baxdıqdan sonra onlardan birini həyata keçirdim. Amma bu, artıq sistemin yeni versiyası idi, çünki... Əslində buna görə çoxlu yazı yazmalı oldum. Nəticə təbii idi, sistemin təsadüfi davranış problemləri aradan qalxdı. Bəziləri deyə bilər ki, proqram təminatının hazırlanması sahəsində səhvlər çox həvəskardır (bir yivli skriptlər, faylda müxtəlif mövzulardan eyni vaxtda bir neçə dəfə əldə edilmiş məlumatların saxlanması və s.). Bəlkə də bu doğrudur, amma mənim əsas işim idarəçilik idi və proqramlaşdırma mənim ruhum üçün yan təlaş idi və mənim sadəcə olaraq proqramçılar komandasında işləmək təcrübəm yox idi, burada belə əsas şeyləri dərhal mənə təklif edərdilər. yoldaşlar. Ona görə də bütün bu qabarıqları özüm doldurdum, amma materialı çox yaxşı öyrəndim. Həm də mənim işim müştərilərlə görüşlər, şirkəti tanıtmağa yönəlmiş tədbirlər, şirkət daxilində bir sıra inzibati məsələlər və daha çox şeyləri əhatə edir. Ancaq bu və ya digər şəkildə, artıq olan şey tələb olunurdu. Uşaqlar və mən gündəlik işimizdə məhsuldan istifadə etdik. Açığı, uğursuz ideyalar və vaxt itkisi ilə nəticələnən həllər var idi, amma sonda məlum oldu ki, bu, işləyən alət deyil və heç kim ondan istifadə etməyib və Veliamda bitməyib.
Helpdesk - Help Desk
HelpDesk-in necə yarandığını qeyd etmək əbəs olmaz. Bu tamam başqa hekayədir, çünki... Veliam-da bu, bütün əvvəlkilərdən fərqli olan 3-cü tamamilə yeni versiyadır. İndi bu, lazımsız zənglər və fitlər olmadan intuitiv, domenlə inteqrasiya imkanı, həmçinin e-poçtdan keçiddən istifadə edərək istənilən yerdən eyni istifadəçi profilinə daxil olmaq imkanı olan sadə bir sistemdir. Ən əsası isə VPN və ya port yönləndirməsi olmadan ərizəçiyə istənilən yerdən (evdə və ya ofisdə) birbaşa tətbiqdən VNC vasitəsilə qoşulmaq mümkündür. Buna necə gəldiyimizi, əvvəllər nə baş verdiyini və hansı dəhşətli qərarların qəbul edildiyini söyləyəcəyəm.
Biz tanınmış TeamViewer vasitəsilə istifadəçilərlə əlaqə saxladıq. İstifadəçilərinə xidmət göstərdiyimiz bütün kompüterlərdə televizor quraşdırılıb. Səhv etdiyimiz və sonradan onu sildiyimiz ilk şey hər bir HD müştərini aparatla əlaqələndirmək oldu. İstifadəçi sorğu buraxmaq üçün HD sisteminə necə daxil olub? Televizordan əlavə, hər kəsin kompüterində Lazarus dilində yazılmış xüsusi bir yardım proqramı var idi (burada bir çox insanlar gözlərini yumacaqlar və bəlkə də Google-a girəcəklər, amma mənim bildiyim ən yaxşı tərtib edilmiş dil Delphi idi və Lazarus demək olar ki, eyni şey, yalnız pulsuz). Ümumiyyətlə, istifadəçi bu yardım proqramını işə salan xüsusi bir toplu faylı işə saldı, bu da öz növbəsində sistemin HWID-ni oxudu və bundan sonra brauzer işə salındı və avtorizasiya baş verdi. Bu niyə edildi? Bəzi şirkətlərdə xidmət göstərilən istifadəçilərin sayı fərdi olaraq hesablanır və hər ay üçün xidmət qiyməti adamların sayına görə müəyyən edilir. Bu başa düşüləndir, siz deyirsiniz, amma niyə hardware ilə bağlıdır? Çox sadədir, bəzi şəxslər evə gələrək ev noutbukundan “burada mənim üçün hər şeyi gözəl et” üslubunda müraciət etdilər. HWID sistemini oxumaqla yanaşı, yardım proqramı cari Teamviewer ID-ni reyestrdən çıxardı və onu bizə ötürdü. Teamviewer inteqrasiya üçün API-yə malikdir. Və biz bu inteqrasiyanı etdik. Ancaq bir tutma var idi. Bu API-lər vasitəsilə istifadəçi bu sessiyanı açıq şəkildə başlatmadıqda və ona qoşulmağa cəhd etdikdən sonra onun kompüterinə qoşulmaq mümkün deyil, o da “təsdiq et” düyməsini sıxmalıdır. O zaman bizə məntiqli görünürdü ki, istifadəçinin tələbi olmadan heç kim qoşulmamalıdır və şəxs kompüterdə olduğu üçün sessiyanı işə salacaq və uzaqdan qoşulma sorğusuna müsbət cavab verəcək. Hər şey səhv çıxdı. Abituriyentlər sessiyaya başlamaq üçün düyməni basmağı unudublar və bunu onlara telefon danışığında bildirməli olublar. Bu, vaxt itirdi və prosesin hər iki tərəfini məyus etdi. Üstəlik, bir insanın sorğu buraxdığı belə anlar heç də qeyri-adi deyil, ancaq nahara gedəndə qoşulmağa icazə verilir. Çünki problem kritik deyil və iş prosesinin kəsilməsini istəmir. Müvafiq olaraq, o, əlaqəyə icazə vermək üçün heç bir düyməni basmayacaq. HelpDesk-ə daxil olarkən əlavə funksionallıq belə ortaya çıxdı - Teamviwer ID-ni oxumaq. Teamviwer-i quraşdırarkən istifadə edilən daimi parolu bilirdik. Daha doğrusu, onu yalnız sistem bilirdi, çünki o, quraşdırıcıya və bizim sistemə daxil edilib. Müvafiq olaraq, tətbiqdən heç bir şey gözləməyə ehtiyac qalmayan bir əlaqə düyməsi var idi, lakin Teamviewer dərhal açıldı və əlaqə yarandı. Nəticədə iki növ mümkün əlaqə var idi. Rəsmi Teamviewer API və özümüz tərəfindən hazırlanmış API vasitəsilə. Təəccübləndiyim odur ki, onlar birincisini istifadə etməyi demək olar ki, dərhal dayandırdılar, baxmayaraq ki, yalnız xüsusi hallarda və istifadəçinin özü icazə verdikdə istifadə etmək göstərişi var idi. Yenə də indi mənə təhlükəsizlik verin. Amma məlum oldu ki, ərizəçilərin buna ehtiyacı yoxdur. Onların hamısı təsdiq düyməsi olmadan onlara qoşulmaqla tamamilə yaxşıdır.
Linux-da multithreadingə keçid
Əvvəlcədən müəyyən edilmiş portlar siyahısının açıqlığı və şəbəkə obyektlərinin sadə pinglənməsi üçün şəbəkə skanerinin keçidinin sürətləndirilməsi məsələsi çoxdan yaranmağa başlayıb. Burada, əlbəttə ki, ağla gələn ilk həll multithreadingdir. Pingə sərf olunan əsas vaxt paketin qaytarılmasını gözlədiyindən və əvvəlki paket qaytarılana qədər növbəti ping başlaya bilməyəcəyindən, hətta 20+ server və şəbəkə avadanlığı olan şirkətlərdə bu, artıq kifayət qədər yavaş işləyirdi. Məsələ ondadır ki, bir paket yox ola bilər, lakin bu barədə dərhal sistem administratoruna məlumat verməyin. O, sadəcə olaraq belə spamları qəbul etməyi çox tez dayandıracaq. Bu o deməkdir ki, əlçatmazlıq haqqında nəticə çıxarmazdan əvvəl hər bir obyektə bir dəfədən çox ping vurmalısınız. Çox təfərrüata varmadan, onu paralelləşdirmək lazımdır, çünki bu edilmədikdə, çox güman ki, sistem administratoru problemi monitorinq sistemindən deyil, müştəridən öyrənəcək.
PHP özü qutudan kənarda çox iş parçacığını dəstəkləmir. Multiprocessing qabiliyyəti, siz çəngəl bilər. Amma əslində məndə artıq bir səsvermə mexanizmi yazılmışdı və onu elə etmək istəyirdim ki, bir dəfə verilənlər bazasından mənə lazım olan bütün qovşaqları sayacam, hər şeyi bir anda ping edim, hər birindən cavab gözləyim və yalnız bundan sonra dərhal yazım. məlumat. Bu oxu sorğularının sayına qənaət edir. Multithreading bu fikrə mükəmməl uyğun gəlir. PHP üçün real multithreading etməyə imkan verən PThreads modulu var, baxmayaraq ki, bunu PHP 7.2-də qurmaq üçün kifayət qədər zəhmət tələb olundu, lakin bu, edildi. Port tarama və ping indi sürətlidir. Və məsələn, əvvəllər dövrə başına 15 saniyə əvəzinə bu proses 2 saniyə çəkməyə başladı. Yaxşı nəticə idi.
Yeni şirkətlərin sürətli auditi
Müxtəlif ölçüləri və aparat xüsusiyyətlərini toplamaq üçün funksionallıq necə yaranıb? Bu sadədir. Bəzən bizə sadəcə olaraq mövcud İT infrastrukturunu yoxlamaq əmri verilir. Yaxşı, eyni şey yeni müştərinin auditini sürətləndirmək üçün lazımdır. Bizə orta və ya böyük bir şirkətə gəlməyə və onların nəyə sahib olduğunu tez bir zamanda anlamağa imkan verəcək bir şey lazım idi. Fikrimcə, daxili şəbəkədə ping yalnız öz həyatlarını çətinləşdirmək istəyənlər tərəfindən bloklanır və təcrübəmizdə onlardan azdır. Amma belə insanlar da var. Müvafiq olaraq, sadə bir ping ilə cihazların olması üçün şəbəkələri tez bir zamanda skan edə bilərsiniz. Sonra onları əlavə edə və bizi maraqlandıran açıq portları skan edə bilərik. Əslində, bu funksionallıq artıq mövcud idi; yalnız mərkəzi serverdən kölə bir əmr əlavə etmək lazım idi ki, göstərilən şəbəkələri skan etsin və tapdığı hər şeyi siyahıya əlavə etsin. Qeyd etməyi unutdum, güman edilirdi ki, bizdə konfiqurasiya edilmiş sistem (qul monitorinq serveri) ilə artıq hazır bir görüntü var idi ki, onu audit zamanı sadəcə müştəridən çıxarıb buludumuza qoşa bilərik.
Ancaq auditin nəticəsi adətən bir dəstə müxtəlif məlumatları ehtiva edir və onlardan biri şəbəkədə hansı cihazların olmasıdır. Hər şeydən əvvəl, bizi Windows serverləri və domenin bir hissəsi kimi Windows iş stansiyaları maraqlandırırdı. Orta və böyük şirkətlərdə domenin olmaması qayda üçün istisnadır. Bir dildə danışmaq üçün orta hesabla, məncə, 100+ adamdır. Bütün Windows maşınları və serverlərindən onların IP və domen administrator hesablarını bilməklə, lakin onların hər birinə heç bir proqram quraşdırmadan məlumat toplamaq üçün bir yol tapmaq lazım idi. WMI interfeysi xilasetmə üçün gəlir. Windows İdarəetmə Alətləri (WMI) hərfi mənada Windows idarəetmə alətləri deməkdir. WMI Windows platforması ilə işləyən kompüter infrastrukturunun müxtəlif hissələrinin işinin mərkəzləşdirilmiş şəkildə idarə edilməsi və monitorinqi üçün əsas texnologiyalardan biridir. Vikidən götürülmüşdür. Sonra, Debian üçün wmic (bu WMI müştərisidir) tərtib etmək üçün yenidən işləməli oldum. Hər şey hazır olduqdan sonra lazım olan məlumat üçün wmic vasitəsilə lazımi qovşaqları sorğulamaq qalırdı. WMI vasitəsilə Windows kompüterindən demək olar ki, hər hansı bir məlumat əldə edə bilərsiniz və üstəlik, onun vasitəsilə kompüteri idarə edə bilərsiniz, məsələn, onu yenidən yükləməyə göndərə bilərsiniz. Sistemimizdəki Windows stansiyaları və serverləri haqqında məlumat toplusu belə ortaya çıxdı. Bundan əlavə, cari sistem yük göstəriciləri haqqında cari məlumatlar var idi. Biz onları daha tez-tez, aparat haqqında məlumatı isə daha az tələb edirik. Bundan sonra audit bir az daha zövqlü oldu.
Proqram təminatının paylanması qərarı
Biz özümüz sistemdən hər gün istifadə edirik və o, hər bir texniki işçi üçün həmişə açıqdır. Və düşündük ki, əlimizdə olanı başqaları ilə bölüşə bilərik. Sistem hələ paylanmağa hazır deyildi. Yerli versiyanın SaaS-ə çevrilməsi üçün çox şey yenidən işlənməli idi. Bunlara sistemin müxtəlif texniki aspektlərində dəyişikliklər (uzaqdan əlaqə, dəstək xidməti), lisenziyalaşdırma üçün modulların təhlili, müştəri məlumat bazalarının parçalanması, hər bir xidmətin miqyasının dəyişdirilməsi və bütün hissələr üçün avtomatik yeniləmə sistemlərinin inkişafı daxildir. Ancaq bu məqalənin ikinci hissəsi olacaq.
Yeniləmələr
Mənbə: www.habr.com