Ĉiuj 1C-programistoj laŭ unu maniero aŭ alia proksime interagas kun IT-servoj kaj rekte kun sistemaj administrantoj. Sed ĉi tiu interago ne ĉiam iras glate. Mi ŝatus rakonti al vi kelkajn amuzajn rakontojn pri tio.
Altrapida komunika kanalo
Plej multaj el niaj klientoj estas grandaj posedaĵoj kun siaj propraj grandaj IT-sekcioj. Kaj klientspecialistoj kutime respondecas pri rezervaj kopioj de informaj datumbazoj. Sed ekzistas ankaŭ relative malgrandaj organizaĵoj. Precipe por ili, ni havas servon laŭ kiu ni prenas sur nin ĉiujn aferojn rilatajn al sekurkopio de ĉio 1C. Ĉi tiu estas la kompanio pri kiu ni parolos en ĉi tiu rakonto.
Nova kliento venis por subteni 1C kaj, interalie, la kontrakto inkludis klaŭzon, ke ni respondecis pri sekurkopioj, kvankam ili havis sian propran sisteman administranton en dungitaro. Kliento-servila datumbazo, MS SQL kiel DBMS. Sufiĉe norma situacio, sed ankoraŭ estis unu nuanco: la ĉefa bazo estis sufiĉe granda, sed la monata kresko estis tre malgranda. Tio estas, la datumbazo enhavis multajn historiajn datumojn. Konsiderante ĉi tiun funkcion, mi starigis rezervajn prizorgajn planojn jene: la unuan sabaton de ĉiu monato plena sekurkopio estis farita, ĝi estis sufiĉe peza, tiam diferenciga kopio estis farita ĉiunokte - relative malgranda volumo, kaj kopio. de la transakcia protokolo ĉiun horon. Plie, plenaj kaj diferencaj kopioj estis ne nur kopiitaj al retrimedo, sed ankaŭ aldone alŝutitaj al nia FTP-servilo. Ĉi tio estas deviga postulo kiam vi provizas ĉi tiun servon.
Ĉio ĉi estis sukcese agordita, funkciigita kaj ĝenerale funkciis sen fiaskoj.
Sed kelkajn monatojn poste, la sistemadministranto en ĉi tiu organizo ŝanĝiĝis. La nova sistemadministranto komencis iom post iom rekonstrui la IT-infrastrukturon de la firmao laŭ modernaj tendencoj. Precipe aperis virtualigo, diskbretoj, aliro estis barita ĉie kaj ĉio, ktp., kio en la ĝenerala kazo, kompreneble, ne povas ne ĝoji. Sed aferoj ne ĉiam iris glate por li; ofte estis problemoj kun la agado de 1C, kio kaŭzis kelkajn malkonsentojn kaj miskomprenojn kun nia subteno. Ankaŭ, oni devas rimarki, ke nia rilato kun li estis ĝenerale sufiĉe malvarma kaj iom streĉita, kio nur pliigis la gradon de streĉiĝo en la okazo de iuj problemoj.
Sed iun matenon montriĝis, ke la servilo de ĉi tiu kliento ne estas disponebla. Mi telefonis al la sistema administranto por ekscii, kio okazis kaj ricevis kiel respondon ion kiel "Nia servilo kraŝis, ni laboras pri ĝi, ne laŭ vi." Nu, estas bone, ke ili funkcias. Ĉi tio signifas, ke la situacio estas sub kontrolo. Post la tagmanĝo, mi revokas, kaj anstataŭ kolero, mi jam povas senti lacecon kaj apation en la voĉo de la administranto. Mi provas eltrovi kio okazis kaj ĉu estas io, kion ni povas fari por helpi? Kiel rezulto de la konversacio, la sekvanta aperis:
Li movis la servilon al nova stokadsistemo kun lastatempe kunvenita atako. Sed io misfunkciis kaj kelkajn tagojn poste ĉi tiu atako sekure kolapsis. Ĉu la regilo forbrulis aŭ io okazis al la diskoj, mi ne precize memoras, sed ĉiuj informoj estis nerepareble perditaj. Kaj la ĉefa afero estis, ke la reto-rimedo kun sekurkopioj ankaŭ finiĝis sur la sama diska tabelo dum diversaj migradoj. Tio estas, kaj la produktiva datumbazo mem kaj ĉiuj ĝiaj rezervaj kopioj estis perditaj. Kaj estas neklare kion fari nun.
Trankviliĝu, mi diras. Ni havas vian noktan sekurkopion. Responde, estis silento, per kiu mi konstatis, ke mi ĵus savis la vivon de viro. Ni komencas diskuti kiel transdoni ĉi tiun kopion al nova, lastatempe deplojita servilo. Sed ankaŭ ĉi tie aperis problemo.
Ĉu vi memoras, kiam mi diris, ke la plena sekurkopio estis sufiĉe granda? Ne vane mi faris ĝin unufoje monate sabate. La fakto estas, ke la kompanio estis malgranda planto, kiu troviĝis malproksime ekster la urbo kaj ilia Interreto estis tre tiel. Ĝis lundo matene, tio estas, dum la semajnfino, ĉi tiu kopio apenaŭ sukcesis esti alŝutita al nia FTP-servilo. Sed ne estis maniero atendi unu aŭ du tagojn, ke ĝi ŝarĝu en la kontraŭa direkto. Post pluraj malsukcesaj provoj transdoni la dosieron, la administranto elprenis la malmolan diskon rekte de la nova servilo, trovis aŭton kun ŝoforo ie kaj rapide rapidis al nia oficejo, feliĉe ni ankoraŭ estas en la sama urbo.
Dum ili staris en nia servilĉambro kaj atendis la kopion de la dosieroj, ni renkontis la unuan fojon, por tiel diri, "persone", trinkis tason da kafo kaj parolis en neformala medio. Mi simpatiis kun lia ĉagreno kaj resendis lin kun plena ŝraŭbo de sekurkopioj, haste restarigante la haltigitan laboron de la firmao.
Poste, ĉiuj niaj petoj al la IT-fako estis solvitaj tre rapide kaj ne plu aperis malkonsentoj.
Kontaktu vian sisteman administranton
Iam, dum tre longa tempo, mi ne povis eldoni 1C por ret-aliro per IIS por unu kliento. Ĝi ŝajnis kiel ordinara tasko, sed estis neniu maniero funkciigi ĉion. Lokaj sistemadministrantoj engaĝiĝis kaj provis malsamajn agordojn kaj agordajn dosierojn. 1C en la reto normale ne volis funkcii iel. Io estis malĝusta, aŭ kun domajnaj sekurecpolitikoj, aŭ kun la loka altnivela fajroŝirmilo, aŭ Dio scias kio alia. En la N-a ripeto, la administranto sendas al mi ligilon kun la vortoj:
- Provu denove uzante ĉi tiujn instrukciojn. Ĉio estas priskribita tie tute detale. Se ĝi ne funkcias, skribu al la aŭtoro de ĉi tiu retejo, eble li povas helpi.
"Ne," mi diras, "ĝi ne helpos."
- Kial?
— Mi estas la aŭtoro de ĉi tiu retejo... (
Kiel rezulto, ni lanĉis ĝin sur Apache sen problemoj. IIS neniam estis venkita.
Unu nivelo pli profunda
Ni havis klienton - malgrandan produktan entreprenon. Ili havis servilon, specon de "klasika" 3 en 1: servilo de terminalo + servilo de aplikaĵo + servilo de datumbazo. Ili funkciis en iu industri-specifa agordo bazita sur UPP, estis ĉirkaŭ 15-20 uzantoj, kaj la agado de la sistemo, principe, konvenis al ĉiuj.
Kiam pasis la tempo, ĉio funkciis pli-malpli stabile. Sed tiam Eŭropo postulis sankciojn kontraŭ Rusio, sekve de kiuj rusoj komencis aĉeti ĉefe enlande produktitajn produktojn, kaj komerco por ĉi tiu kompanio akre iris supren. La nombro de uzantoj pliiĝis al 50-60 homoj, nova branĉo estis malfermita, kaj dokumenta fluo pliiĝis laŭe. Kaj nun la nuna servilo ne plu povis elteni la akre pliigitan ŝarĝon, kaj 1C komencis, kiel oni diras, "malrapidiĝi". Dum pintaj horoj dokumentoj estis prilaboritaj dum kelkaj minutoj, blokado de eraroj okazis, formoj daŭris longan tempon por malfermiĝi, kaj la tuta alia bukedo da rilataj servoj. La loka sistema administranto forigis ĉiujn problemojn, dirante: "Ĉi tio estas via 1C, vi eltrovos ĝin." Ni plurfoje proponis fari rendimentan revizion de la sistemo, sed ĝi neniam venis al la revizio mem. La kliento simple petis rekomendojn pri kiel ripari problemojn.
Nu, mi sidiĝis kaj skribis sufiĉe longan leteron pri la neceso apartigi la rolojn de la terminala servilo kaj la aplikaĵoservilo per la DBMS (kion, principe, ni jam multfoje antaŭe diris). Mi skribis pri DFSS en terminalserviloj, pri Kundividita Memoro, provizis ligilojn al aŭtoritataj fontoj, kaj eĉ proponis kelkajn eblojn por ekipaĵo. Ĉi tiu letero atingis tiujn en potenco en la firmao, revenis al la IT-fako kun la rezolucioj "Efektivigi" kaj la glacio estis ĝenerale rompita.
Post iom da tempo, la administranto sendas al mi la IP-adreson de la nova servilo kaj ensalutajn akreditaĵojn. Li diras, ke MS SQL kaj 1C-servilo-komponentoj estas deplojitaj tie, kaj la datumbazoj devas esti translokigitaj, sed nuntempe nur al la DBMS-servilo, ĉar kelkaj problemoj ekestis kun la 1C-ŝlosiloj.
Mi eniris, efektive, ĉiuj servoj funkciis, la servilo ne estis tre potenca, sed bone, mi pensas, ke ĝi estas pli bona ol nenio. Mi transdonos la datumbazojn nuntempe por iel malpezigi la nunan servilon. Mi kompletigis ĉiujn translokojn je la interkonsentita tempo, sed la situacio ne ŝanĝiĝis - ankoraŭ la samaj agadoproblemoj. Estas strange, kompreneble, nu, ni registri la datumbazojn en la 1C-grupo kaj ni vidos.
Pluraj tagoj pasas, la ŝlosiloj ne estis transdonitaj. Mi scivolas, kio estas la problemo, ĉio ŝajnas esti simpla - elprenu ĝin el unu servilo, ŝtopu ĝin en alian, instalu la pelilon kaj vi finis. La administranto respondas fuŝante kaj dirante ion pri havena plusendado, virtuala servilo, ktp.
Hmm... Virtuala servilo? Ŝajnas, ke neniam okazis virtualigo kaj neniam okazis... Mi memoras sufiĉe konatan problemon pri la malebleco plusendi 1C-servilan ŝlosilon al virtuala maŝino sur Hyper-V en Windows Server 2008. Kaj ĉi tie iuj suspektoj komencas formiĝi en mi...
Mi malfermas la servilon-administranton - Roloj - aperis nova rolo - Hyper-V. Mi iras al la administranto de Hyper-V, vidas unu virtualan maŝinon, konektas... Kaj efektive... Nia nova datumbaza servilo...
Do kio? La instrukcioj de la aŭtoritatoj kaj miaj rekomendoj estis plenumitaj, la roloj estis apartigitaj. La tasko povas esti fermita.
Post iom da tempo, la nuna krizo okazis, la nova branĉo devis esti fermita, la ŝarĝo malpliiĝis, kaj la sistema rendimento fariĝis pli-malpli tolerebla.
Nu, kompreneble, ili ne povis plusendi la servilan ŝlosilon al la virtuala maŝino. Kiel rezulto, ĉio estis lasita kiel estas: terminalservilo + 1C areto sur fizika maŝino, datumbaza servilo tie en virtuala.
Kaj estus bone, se ĉi tio estus ia oficejo de ŝaraŝkin. Do ne. Konata kompanio, kies produktojn vi verŝajne konas kaj vidis en la koncernaj fakoj de ĉiuj Lentas kaj Auchans.
Malmola disko feria horaro
Granda holdingo kun ambiciaj planoj transpreni la mondon denove aĉetis malgrandan kompanion kun la celo inkluzivi ĝin en sia mega-korporacio. En ĉiuj sekcioj de ĉi tiu holdingo, uzantoj laboras en siaj propraj datumbazoj, sed kun identa agordo. Kaj do ni komencis malgrandan projekton por inkludi novan unuon en ĉi tiu sistemo.
Antaŭ ĉio, necesas disfaldi produktajn kaj testajn datumbazojn. La programisto ricevis la konektajn datumojn, ensalutas en la servilon, vidas MS SQL instalita, 1C-servilo, vidas 2 logikaj diskoj: stirado "C" kun kapablo de 250 gigabajtoj kaj stirado "D" kun kapablo de 1 terabajto. Nu, "C" estas la sistemo, "D" estas por datumoj, la programisto logike decidas kaj deplojas ĉiujn datumbazojn tie. Mi eĉ starigis prizorgajn planojn, inkluzive de sekurkopio, ĉiaokaze (kvankam ni ne respondecas pri tio). Vere, sekurkopioj estis aldonitaj ĉi tie al "D". En la estonteco, estis planite reagordi ĝin al iu aparta retrimedo.
La projekto komenciĝis, konsultistoj disponigis trejnadon pri kiel labori en la nova sistemo, restaĵoj estis transdonitaj, kelkaj negravaj plibonigoj estis faritaj, kaj uzantoj komencis labori en la nova informbazo.
Ĉio iris bone ĝis unu lundon matene, kiam oni malkovris, ke la datumbaza disko mankas. Simple ne estas "D" sur la servilo kaj jen ĝi.
Plia esploro malkaŝis ĉi tion: ĉi tiu "servilo" fakte estis la laborkomputilo de loka sistema administranto. Vere, ĝi ankoraŭ havis servilon OS. La persona USB-disko de ĉi tiu administranto estis konektita al la servilo. Kaj tiel la administranto foriris feriojn, kunportante sian ŝraŭbon, kun la celo enpumpi en ĝi filmojn por la vojaĝo.
Dankon al Dio, li ne sukcesis forigi la datumbazdosierojn kaj sukcesis restarigi la produktivan datumbazon.
Estas rimarkinde, ke ĉiuj ĝenerale kontentiĝis pri la agado de la sistemo situanta sur USB-disko. Neniu plendis pri ia nekontentiga agado de 1C. Nur poste la holdingo komencis mega-projekton por transdoni ĉiujn informajn datumbazojn al ununura centralizita retejo kun super-serviloj, stoksistemoj por miliono+ rubloj, sofistikaj hiperviziiloj kaj neelteneblaj 1C-bremsoj en ĉiuj branĉoj.
Sed tio estas tute alia historio...
fonto: www.habr.com