Të gjithë zhvilluesit e 1C në një mënyrë ose në një tjetër ndërveprojnë ngushtë me shërbimet e IT dhe drejtpërdrejt me administratorët e sistemit. Por ky ndërveprim nuk shkon gjithmonë pa probleme. Do të doja t'ju tregoja disa histori qesharake për këtë.
Kanal komunikimi me shpejtësi të lartë
Shumica e klientëve tanë janë prona të mëdha me departamentet e tyre të mëdha IT. Dhe specialistët e klientëve zakonisht janë përgjegjës për kopjet rezervë të bazave të të dhënave të informacionit. Por ka edhe organizata relativisht të vogla. Sidomos për ta, ne kemi një shërbim sipas të cilit marrim mbi vete të gjitha çështjet që lidhen me kopjen rezervë të gjithçkaje 1C. Kjo është kompania për të cilën do të flasim në këtë histori.
Një klient i ri erdhi për të mbështetur 1C dhe, ndër të tjera, kontrata përfshinte një klauzolë që ne ishim përgjegjës për kopjet rezervë, megjithëse ata kishin administratorin e tyre të sistemit në staf. Baza e të dhënave klient-server, MS SQL si një DBMS. Një situatë mjaft standarde, por kishte ende një nuancë: baza kryesore ishte mjaft e madhe, por rritja mujore ishte shumë e vogël. Kjo do të thotë, baza e të dhënave përmbante shumë të dhëna historike. Duke marrë parasysh këtë veçori, unë vendosa planet e mirëmbajtjes rezervë si më poshtë: të shtunën e parë të çdo muaji u bë një kopje rezervë e plotë, ishte mjaft e rëndë, më pas bëhej një kopje diferenciale çdo natë - një vëllim relativisht i vogël dhe një kopje e regjistrit të transaksioneve çdo orë. Për më tepër, kopjet e plota dhe diferenciale jo vetëm që u kopjuan në një burim rrjeti, por gjithashtu u ngarkuan gjithashtu në serverin tonë FTP. Kjo është një kërkesë e detyrueshme kur ofrohet ky shërbim.
E gjithë kjo u konfigurua me sukses, u vu në punë dhe në përgjithësi funksionoi pa dështime.
Por disa muaj më vonë, administratori i sistemit në këtë organizatë ndryshoi. Administratori i ri i sistemit filloi të rindërtojë gradualisht infrastrukturën e IT të kompanisë në përputhje me tendencat moderne. Në veçanti, u shfaq virtualizimi, raftet e diskut, qasja u bllokua kudo dhe gjithçka, etj., Të cilat në rastin e përgjithshëm, natyrisht, nuk mund të mos gëzohen. Por gjërat nuk shkonin gjithmonë mirë për të; shpesh kishte probleme me performancën e 1C, gjë që shkaktoi disa mosmarrëveshje dhe keqkuptime me mbështetjen tonë. Gjithashtu, duhet theksuar se marrëdhënia jonë me të në përgjithësi ishte mjaft e ftohtë dhe disi e tensionuar, gjë që vetëm sa rriti shkallën e tensionit në rast të ndonjë problemi.
Por një mëngjes doli që serveri i këtij klienti nuk ishte i disponueshëm. Telefonova administratorin e sistemit për të mësuar se çfarë ndodhi dhe mora si përgjigje diçka të tillë si "Serveri ynë ka dështuar, ne po punojmë për të, nuk varet nga ju". Epo, është mirë që ata punojnë. Kjo do të thotë se situata është nën kontroll. Pas drekës, telefonoj përsëri dhe në vend të acarimit, tashmë ndjej lodhje dhe apati në zërin e administratorit. Po përpiqem të kuptoj se çfarë ndodhi dhe a mund të bëjmë ndonjë gjë për të ndihmuar? Si rezultat i bisedës, dolën si më poshtë:
Ai e zhvendosi serverin në një sistem të ri ruajtjeje me një bastisje të sapombledhur. Por diçka shkoi keq dhe disa ditë më vonë kjo bastisje u shemb në mënyrë të sigurtë. Nëse kontrolluesi u dogj ose ndodhi diçka me disqet, nuk e mbaj mend saktësisht, por i gjithë informacioni humbi në mënyrë të pakthyeshme. Dhe gjëja kryesore ishte që burimi i rrjetit me kopje rezervë gjithashtu përfundoi në të njëjtin grup disku gjatë migrimeve të ndryshme. Kjo do të thotë, si vetë baza e të dhënave produktive ashtu edhe të gjitha kopjet rezervë të saj humbën. Dhe është e paqartë se çfarë të bëhet tani.
Qetësohu, i them. Ne kemi rezervën tuaj të natës. Si përgjigje, pati heshtje, me të cilën kuptova se sapo kisha shpëtuar jetën e një njeriu. Ne fillojmë të diskutojmë se si ta transferojmë këtë kopje në një server të ri, të vendosur rishtazi. Por edhe këtu lindi një problem.
Ju kujtohet kur thashë se rezervimi i plotë ishte mjaft i madh? Jo më kot e bëja një herë në muaj të shtunave. Fakti është se kompania ishte një fabrikë e vogël, e cila ndodhej shumë jashtë qytetit dhe interneti i tyre ishte shumë i tillë. Deri të hënën në mëngjes, domethënë gjatë fundjavës, kjo kopje mezi arriti të ngarkohej në serverin tonë FTP. Por nuk kishte si të priste një ose dy ditë që të ngarkohej në drejtim të kundërt. Pas disa përpjekjeve të pasuksesshme për të transferuar skedarin, administratori nxori hard diskun direkt nga serveri i ri, gjeti një makinë me një shofer diku dhe shpejt nxitoi në zyrën tonë, për fat të mirë jemi ende në të njëjtin qytet.
Ndërsa ata po qëndronin në dhomën tonë të serverit dhe prisnin që skedarët të kopjoheshin, ne u takuam për herë të parë, si të thuash, “personalisht”, pimë një filxhan kafe dhe biseduam në një mjedis joformal. Unë e simpatizova pikëllimin e tij dhe e ktheva me një vidë të plotë rezervash, duke rivendosur me nxitim punën e ndërprerë të kompanisë.
Më pas, të gjitha kërkesat tona për departamentin e IT-së u zgjidhën shumë shpejt dhe nuk pati më mosmarrëveshje.
Kontaktoni administratorin e sistemit tuaj
Një herë, për një kohë shumë të gjatë, nuk mund të publikoja 1C për qasje në internet përmes IIS për një klient. Dukej si një detyrë e zakonshme, por nuk kishte asnjë mënyrë për të nisur gjithçka. Administratorët e sistemit lokal u përfshinë dhe provuan cilësime të ndryshme dhe skedarë konfigurimi. 1C në ueb normalisht nuk donte të punonte në asnjë mënyrë. Diçka nuk ishte në rregull, ose me politikat e sigurisë së domenit, ose me murin mbrojtës të sofistikuar lokal, ose një Zot e di se çfarë tjetër. Në përsëritjen e nëntë, administratori më dërgon një lidhje me fjalët:
- Provoni përsëri duke përdorur këto udhëzime. Gjithçka përshkruhet atje në mënyrë mjaft të detajuar. Nëse nuk funksionon, shkruani autorit të kësaj faqeje, mbase ai mund të ndihmojë.
"Jo," them unë, "nuk do të ndihmojë."
- Pse
— Unë jam autori i kësaj faqeje... (
Si rezultat, ne e nisëm atë në Apache pa asnjë problem. IIS nuk u mposht kurrë.
Një nivel më thellë
Ne kishim një klient - një ndërmarrje të vogël prodhuese. Ata kishin një server, një lloj "klasik" 3 në 1: server terminal + server aplikacioni + server të bazës së të dhënave. Ata punuan në disa konfigurime specifike të industrisë bazuar në UPP, kishte rreth 15-20 përdorues dhe performanca e sistemit, në parim, i përshtatej të gjithëve.
Me kalimin e kohës, gjithçka funksiononte pak a shumë në mënyrë të qëndrueshme. Por më pas Evropa vendosi sanksione kundër Rusisë, si rezultat i të cilave rusët filluan të blejnë produkte kryesisht të prodhuara në vend, dhe biznesi për këtë kompani shkoi përpjetë ndjeshëm. Numri i përdoruesve u rrit në 50-60 persona, u hap një degë e re dhe rrjedha e dokumenteve u rrit në përputhje me rrethanat. Dhe tani serveri aktual nuk mund të përballonte më ngarkesën e rritur ndjeshëm, dhe 1C filloi, siç thonë ata, të "ngadalësohej". Gjatë orëve të pikut, dokumentet përpunoheshin për disa minuta, ndodhën gabime në bllokim, hapja e formularëve u desh shumë dhe e gjithë buqeta e tjera e shërbimeve përkatëse. Administratori lokal i sistemit fshiu të gjitha problemet, duke thënë: "Ky është 1C juaj, ju do ta kuptoni". Ne kemi propozuar në mënyrë të përsëritur kryerjen e një auditimi të performancës së sistemit, por asnjëherë nuk ka ardhur deri te vetë auditimi. Klienti thjesht kërkoi rekomandime se si të rregullonte problemet.
Epo, unë u ula dhe shkrova një letër mjaft të gjatë në lidhje me nevojën për të ndarë rolet e serverit terminal dhe serverit të aplikacionit me DBMS (gjë që, në parim, e kemi thënë tashmë shumë herë më parë). Kam shkruar për DFSS në serverët e terminalit, për memorien e përbashkët, kam ofruar lidhje me burime autoritative dhe madje sugjerova disa opsione për pajisje. Kjo letër arriti tek ata që ishin në pushtet në kompani, u kthye në departamentin e IT me rezolutat "Implemento" dhe akulli në përgjithësi u thye.
Pas ca kohësh, administratori më dërgon adresën IP të serverit të ri dhe kredencialet e hyrjes. Ai thotë se përbërësit e serverit MS SQL dhe 1C janë vendosur atje, dhe bazat e të dhënave duhet të transferohen, por tani për tani vetëm në serverin DBMS, pasi kanë lindur disa probleme me çelësat 1C.
Hyra, me të vërtetë, të gjitha shërbimet po funksiononin, serveri nuk ishte shumë i fuqishëm, por ok, mendoj se është më mirë se asgjë. Tani për tani do të transferoj bazat e të dhënave në mënyrë që të lehtësoj disi serverin aktual. I përfundova të gjitha transferimet në kohën e rënë dakord, por situata nuk ndryshoi - ende të njëjtat probleme të performancës. Është e çuditshme, natyrisht, mirë, le të regjistrojmë bazat e të dhënave në grupin 1C dhe do të shohim.
Kanë kaluar disa ditë, çelësat nuk janë transferuar. Po pyes veten se cili është problemi, gjithçka duket të jetë e thjeshtë - hiqeni nga një server, futeni në një tjetër, instaloni drejtuesin dhe keni mbaruar. Administratori përgjigjet duke ngatërruar dhe duke thënë diçka në lidhje me përcjelljen e portit, një server virtual, e kështu me radhë.
Hmm... Server virtual? Duket se nuk ka pasur kurrë dhe nuk ka pasur kurrë ndonjë virtualizim... Më kujtohet një problem mjaft i njohur me pamundësinë e përcjelljes së çelësit të serverit 1C në një makinë virtuale në Hyper-V në Windows Server 2008. Dhe këtu disa dyshime fillojnë të krijohen tek unë...
Unë hap menaxherin e serverit - Rolet - është shfaqur një rol i ri - Hyper-V. Shkoj te menaxheri i Hyper-V, shoh një makinë virtuale, lidhem... Dhe vërtet... Serveri ynë i ri i bazës së të dhënave...
Edhe çfarë? Udhëzimet e autoriteteve dhe rekomandimet e mia janë realizuar, rolet janë ndarë. Detyra mund të mbyllet.
Pas ca kohësh, ndodhi kriza tani, dega e re duhej të mbyllej, ngarkesa u ul dhe performanca e sistemit u bë pak a shumë e tolerueshme.
Epo, sigurisht, ata nuk mund ta përcjellin çelësin e serverit në makinën virtuale. Si rezultat, gjithçka mbeti ashtu siç është: serveri i terminalit + grupi 1C në një makinë fizike, serveri i bazës së të dhënave atje në një virtual.
Dhe do të ishte mirë nëse kjo do të ishte një lloj zyre sharashkin. Pra jo. Një kompani e njohur, produktet e së cilës me siguri i njihni dhe i keni parë në departamentet përkatëse të të gjitha Lentas dhe Auchans.
Orari i pushimeve në hard drive
Një kompani e madhe holding me plane ambicioze për të marrë përsipër botën ka blerë edhe një herë një kompani të vogël me synimin për ta përfshirë në mega-korporatën e saj. Në të gjitha ndarjet e kësaj kompanie, përdoruesit punojnë në bazat e tyre të të dhënave, por me një konfigurim identik. Dhe kështu filluam një projekt të vogël për të përfshirë një njësi të re në këtë sistem.
Para së gjithash, është e nevojshme të vendosen bazat e të dhënave të prodhimit dhe testimit. Zhvilluesi mori të dhënat e lidhjes, regjistrohet në server, sheh të instaluar MS SQL, serverin 1C, sheh 2 disqe logjike: disku "C" me një kapacitet 250 gigabajt dhe disku "D" me një kapacitet 1 terabajt. Epo, "C" është sistemi, "D" është për të dhënat, zhvilluesi logjikisht vendos dhe vendos të gjitha bazat e të dhënave atje. Unë madje kam krijuar plane mirëmbajtjeje, duke përfshirë rezervimin, për çdo rast (edhe pse ne nuk jemi përgjegjës për këtë). Vërtetë, kopjet rezervë u shtuan këtu në "D". Në të ardhmen, ishte planifikuar të rikonfigurohej në një burim të veçantë rrjeti.
Projekti filloi, konsulentët ofruan trajnime se si të punonin në sistemin e ri, u transferuan mbetjet, u bënë disa përmirësime të vogla të vogla dhe përdoruesit filluan të punojnë në bazën e re të informacionit.
Gjithçka po shkonte mirë deri në mëngjesin e një të hëne kur u zbulua se disku i bazës së të dhënave mungonte. Thjesht nuk ka "D" në server dhe kaq.
Hetimi i mëtejshëm zbuloi këtë: ky "server" ishte në fakt kompjuteri i punës i një administratori të sistemit lokal. Vërtetë, ai ende kishte një OS server. Disku personal USB i këtij administratori u lidh në server. Dhe kështu administratori shkoi me pushime, duke marrë vidën me vete, me synimin për të pompuar filma në të për udhëtim.
Falë Zotit, ai nuk arriti të fshinte skedarët e bazës së të dhënave dhe arriti të rivendoste bazën e të dhënave produktive.
Vlen të përmendet se të gjithë ishin përgjithësisht të kënaqur me performancën e sistemit të vendosur në një disk USB. Askush nuk u ankua për ndonjë performancë të pakënaqshme të 1C. Ishte vetëm më vonë që Holding filloi një mega-projekt për transferimin e të gjitha bazave të të dhënave të informacionit në një sit të vetëm të centralizuar me super-server, sisteme ruajtjeje për një milion+ rubla, hipervizorë të sofistikuar dhe frena të padurueshme 1C në të gjitha degët.
Por kjo është një histori krejtësisht tjetër ...
Burimi: www.habr.com