Toți dezvoltatorii 1C într-un fel sau altul interacționează îndeaproape cu serviciile IT și direct cu administratorii de sistem. Dar această interacțiune nu decurge întotdeauna fără probleme. Aș vrea să vă spun câteva povești amuzante despre asta.
Canal de comunicare de mare viteză
Majoritatea clienților noștri sunt holdinguri mari, cu propriile lor departamente IT mari. Și specialiștii clienți sunt de obicei responsabili pentru copiile de rezervă ale bazelor de date de informații. Dar există și organizații relativ mici. Mai ales pentru ei, avem un serviciu conform căruia ne luăm asupra noastră toate problemele legate de backup-ul a tot 1C. Aceasta este compania despre care vom vorbi în această poveste.
Un nou client a venit să susțină 1C și, printre altele, contractul includea o clauză conform căreia noi eram responsabili de backup, deși aveau propriul administrator de sistem în personal. Baza de date client-server, MS SQL ca SGBD. O situație destul de standard, dar mai exista o nuanță: baza principală a fost destul de mare, dar creșterea lunară a fost foarte mică. Adică baza de date conținea o mulțime de date istorice. Ținând cont de această caracteristică, am configurat planuri de întreținere de rezervă după cum urmează: în prima sâmbătă a fiecărei luni s-a făcut o copie de rezervă completă, a fost destul de grea, apoi s-a făcut o copie diferențială în fiecare seară - un volum relativ mic și o copie din jurnalul de tranzacții în fiecare oră. Mai mult, copiile complete și diferențiale nu au fost doar copiate într-o resursă de rețea, ci și încărcate suplimentar pe serverul nostru FTP. Aceasta este o cerință obligatorie la furnizarea acestui serviciu.
Toate acestea au fost configurate cu succes, puse în funcțiune și au funcționat în general fără erori.
Dar câteva luni mai târziu, administratorul de sistem din această organizație s-a schimbat. Noul administrator de sistem a început să reconstruiască treptat infrastructura IT a companiei, în conformitate cu tendințele moderne. În special, a apărut virtualizarea, rafturile de discuri, accesul a fost blocat peste tot și totul etc., ceea ce în cazul general, desigur, nu poate decât să se bucure. Dar lucrurile nu au mers întotdeauna bine pentru el, au existat adesea probleme cu performanța lui 1C, ceea ce a provocat unele dezacorduri și neînțelegeri cu sprijinul nostru. De asemenea, trebuie menționat că relația noastră cu el a fost în general destul de rece și oarecum încordată, ceea ce nu face decât să mărească gradul de tensiune în cazul apariției oricăror probleme.
Dar într-o dimineață s-a dovedit că serverul acestui client nu era disponibil. Am sunat administratorul de sistem pentru a afla ce s-a întâmplat și am primit ca răspuns ceva de genul „Serverul nostru s-a prăbușit, lucrăm la el, nu depinde de tine”. Ei bine, e bine că funcționează. Aceasta înseamnă că situația este sub control. După prânz, sun din nou și, în loc de iritare, simt deja oboseală și apatie în vocea administratorului. Încerc să-mi dau seama ce s-a întâmplat și putem face ceva pentru a ajuta? În urma conversației, au reieșit următoarele:
A mutat serverul la un nou sistem de stocare cu un raid nou asamblat. Dar ceva a mers prost și câteva zile mai târziu acest raid s-a prăbușit în siguranță. Indiferent dacă controlerul s-a ars sau s-a întâmplat ceva cu discurile, nu-mi amintesc exact, dar toate informațiile s-au pierdut iremediabil. Și principalul lucru a fost că resursa de rețea cu copii de siguranță a ajuns, de asemenea, pe aceeași matrice de discuri în timpul diferitelor migrări. Adică, atât baza de date productivă în sine, cât și toate copiile de rezervă au fost pierdute. Și nu este clar ce să faci acum.
Calmează-te, zic. Avem backup-ul tău seara. Ca răspuns, a fost tăcere, prin care mi-am dat seama că tocmai salvasem viața unui bărbat. Începem să discutăm despre cum să transferăm această copie pe un server nou, nou implementat. Dar și aici a apărut o problemă.
Îți amintești când am spus că backupul complet era destul de mare? Nu degeaba o făceam o dată pe lună sâmbăta. Cert este că compania era o fabrică mică, care era situată departe în afara orașului, iar internetul lor era foarte așa-așa. Până luni dimineață, adică în weekend, această copie abia a reușit să fie încărcată pe serverul nostru FTP. Dar nu era nicio modalitate de a aștepta o zi sau două până se încarcă în direcția opusă. După mai multe încercări nereușite de a transfera fișierul, administratorul a scos hard disk-ul direct de pe noul server, a găsit undeva o mașină cu șofer și s-a repezit repede la biroul nostru, din fericire suntem încă în același oraș.
În timp ce stăteau în camera noastră de server și așteptau ca fișierele să fie copiate, ne-am întâlnit pentru prima dată, ca să spunem așa, „în persoană”, am băut o ceașcă de cafea și am vorbit într-un cadru informal. Am simpatizat cu durerea lui și l-am trimis înapoi cu un șurub plin de copii de rezervă, restabilind în grabă munca oprită a companiei.
Ulterior, toate solicitările noastre către departamentul IT au fost rezolvate foarte rapid și nu au mai apărut neînțelegeri.
Contactați administratorul de sistem
Odată, de foarte mult timp, nu am putut publica 1C pentru acces web prin IIS pentru un client. Părea o sarcină obișnuită, dar nu exista nicio modalitate de a pune totul în funcțiune. Administratorii locali de sistem s-au implicat și au încercat diferite setări și fișiere de configurare. 1C de pe web în mod normal nu dorea să funcționeze în niciun fel. Ceva a fost în neregulă, fie cu politicile de securitate ale domeniului, fie cu firewall-ul sofisticat local, fie Dumnezeu știe ce altceva. La a N-a iterație, administratorul îmi trimite un link cu cuvintele:
- Încercați din nou folosind aceste instrucțiuni. Totul este descris acolo destul de detaliat. Dacă nu funcționează, scrieți-i autorului acestui site, poate vă poate ajuta.
„Nu”, spun eu, „nu va ajuta”.
- De ce?
— Sunt autorul acestui site... (
Drept urmare, l-am lansat pe Apache fără probleme. IIS nu a fost niciodată învins.
Cu un nivel mai adânc
Aveam un client - o mică întreprindere de producție. Aveau un server, un fel de „clasic” 3 în 1: server terminal + server de aplicații + server de baze de date. Au funcționat într-o configurație specifică industriei bazate pe UPP, erau aproximativ 15-20 de utilizatori, iar performanța sistemului, în principiu, se potrivea tuturor.
Odată cu trecerea timpului, totul a funcționat mai mult sau mai puțin stabil. Dar apoi Europa a impus sancțiuni împotriva Rusiei, în urma cărora rușii au început să cumpere în principal produse produse pe piața internă, iar afacerile acestei companii au crescut brusc. Numărul de utilizatori a crescut la 50-60 de persoane, a fost deschisă o nouă filială, iar fluxul de documente a crescut în consecință. Și acum serverul actual nu a mai putut face față sarcinii crescute brusc, iar 1C a început, după cum se spune, să „încetinească”. În orele de vârf, documentele au fost procesate timp de câteva minute, au apărut erori de blocare, formularele au durat mult să se deschidă și întregul buchet de servicii conexe. Administratorul local de sistem a eliminat toate problemele, spunând: „Acesta este 1C-ul tău, o să-ți dai seama.” Am propus în mod repetat efectuarea unui audit de performanță al sistemului, dar nu a ajuns niciodată la auditul în sine. Clientul a cerut pur și simplu recomandări despre cum să remedieze problemele.
Ei bine, m-am așezat și am scris o scrisoare destul de lungă despre necesitatea de a separa rolurile serverului terminal și ale serverului de aplicații cu SGBD (ceea ce, în principiu, am spus deja de multe ori). Am scris despre DFSS pe serverele terminale, despre Shared Memory, am oferit link-uri către surse autorizate și chiar am sugerat câteva opțiuni pentru echipamente. Această scrisoare a ajuns la cei de la putere în companie, a revenit la departamentul IT cu rezoluțiile „Implementare” și gheața s-a spart în general.
După ceva timp, administratorul îmi trimite adresa IP a noului server și acreditările de conectare. El spune că acolo sunt implementate componente MS SQL și serverul 1C, iar bazele de date trebuie transferate, dar deocamdată doar pe serverul DBMS, deoarece au apărut unele probleme cu cheile 1C.
Am intrat, într-adevăr, toate serviciile rulau, serverul nu era foarte puternic, dar ok, cred că e mai bine decât nimic. Voi transfera bazele de date deocamdată pentru a elibera cumva serverul actual. Am finalizat toate transferurile la ora convenită, dar situația nu s-a schimbat - tot aceleași probleme de performanță. Este ciudat, desigur, ei bine, să înregistrăm bazele de date în clusterul 1C și vom vedea.
Trec câteva zile, cheile nu au fost transferate. Mă întreb care este problema, totul pare a fi simplu - scoateți-l de pe un server, conectați-l la altul, instalați driverul și gata. Administratorul răspunde frământându-se și spunând ceva despre redirecționarea portului, un server virtual și așa mai departe.
Hmm... Server virtual? Se pare că nu a existat niciodată vreo virtualizare și nu a existat niciodată... Îmi amintesc de o problemă destul de cunoscută cu imposibilitatea redirecționării unei chei de server 1C către o mașină virtuală pe Hyper-V în Windows Server 2008. Și aici unele suspiciuni încep să se formeze în mine...
Deschid serverul manager - Roluri - a apărut un nou rol - Hyper-V. Mă duc la managerul Hyper-V, văd o mașină virtuală, mă conectez... Și într-adevăr... Noul nostru server de baze de date...
Şi ce dacă? Instrucțiunile autorităților și recomandările mele au fost îndeplinite, rolurile au fost separate. Sarcina poate fi închisă.
După ceva timp, criza de acum a avut loc, noua sucursală a trebuit să fie închisă, sarcina a scăzut, iar performanța sistemului a devenit mai mult sau mai puțin tolerabilă.
Ei bine, desigur, nu au putut transmite cheia serverului către mașina virtuală. Ca urmare, totul a fost lăsat așa cum este: server terminal + cluster 1C pe o mașină fizică, server de bază de date acolo într-una virtuală.
Și ar fi bine dacă acesta ar fi un fel de birou al lui Sharashkin. Deci nu. O companie cunoscută ale cărei produse probabil le cunoașteți și le-ați văzut în departamentele relevante ale tuturor Lentas și Auchans.
Program de vacanță pe hard disk
Un mare holding cu planuri ambițioase de a prelua lumea a cumpărat din nou o companie mică cu scopul de a o include în mega-corporația sa. În toate diviziile acestei exploatații, utilizatorii lucrează în propriile baze de date, dar cu o configurație identică. Și așa am început un mic proiect pentru a include o nouă unitate în acest sistem.
În primul rând, este necesară implementarea bazelor de date de producție și testare. Dezvoltatorul a primit datele de conectare, se conectează la server, vede MS SQL instalat, serverul 1C, vede 2 unități logice: unitatea „C” cu o capacitate de 250 gigaocteți și unitatea „D” cu o capacitate de 1 terabyte. Ei bine, „C” este sistemul, „D” este pentru date, dezvoltatorul decide și implementează în mod logic toate bazele de date acolo. Am stabilit chiar și planuri de întreținere, inclusiv backup, pentru orice eventualitate (chiar dacă nu suntem responsabili pentru asta). Adevărat, copiile de rezervă au fost adăugate aici la „D”. În viitor, s-a planificat reconfigurarea acestuia la o resursă de rețea separată.
Proiectul a început, consultanții au oferit instruire cu privire la modul de lucru în noul sistem, au fost transferate resturi, au fost făcute unele îmbunătățiri minore minore, iar utilizatorii au început să lucreze în noua bază de informații.
Totul mergea bine până într-o dimineață de luni când s-a descoperit că discul bazei de date lipsește. Pur și simplu nu există „D” pe server și atât.
Investigațiile ulterioare au relevat acest lucru: acest „server” era de fapt computerul de lucru al unui administrator de sistem local. Adevărat, avea încă un sistem de operare server. Unitatea USB personală a acestui administrator a fost conectată la server. Și așa administratorul a plecat în vacanță, luându-și șurubul cu el, cu scopul de a pompa filme în el pentru călătorie.
Slavă Domnului, nu a reușit să ștergă fișierele bazei de date și a reușit să restaureze baza de date productivă.
Este de remarcat faptul că toată lumea a fost în general mulțumită de performanța sistemului situat pe o unitate USB. Nimeni nu s-a plâns de vreo performanță nesatisfăcătoare a 1C. Abia mai târziu, holdingul a început un mega-proiect pentru a transfera toate bazele de date de informații pe un singur site centralizat cu super-servere, sisteme de stocare pentru peste un milion de ruble, hipervizoare sofisticate și frâne 1C insuportabile în toate ramurile.
Dar asta e cu totul alta poveste...
Sursa: www.habr.com