Mga kwento ng developer ng 1C: ng admin

Ang lahat ng mga developer ng 1C sa isang paraan o iba ay malapit na nakikipag-ugnayan sa mga serbisyo ng IT at direkta sa mga administrator ng system. Ngunit ang pakikipag-ugnayang ito ay hindi laging maayos. Nais kong sabihin sa iyo ang ilang mga nakakatawang kwento tungkol dito.

High-speed na channel ng komunikasyon

Karamihan sa aming mga kliyente ay malalaking pag-aari na may sariling malalaking departamento ng IT. At ang mga espesyalista sa kliyente ay karaniwang responsable para sa mga backup na kopya ng mga database ng impormasyon. Ngunit mayroon ding mga maliliit na organisasyon. Lalo na para sa kanila, mayroon kaming isang serbisyo ayon sa kung saan inaako namin ang lahat ng mga isyu na may kaugnayan sa backup ng lahat ng 1C. Ito ang kumpanyang pag-uusapan natin sa kwentong ito.

Isang bagong kliyente ang dumating upang suportahan ang 1C at, bukod sa iba pang mga bagay, kasama sa kontrata ang isang sugnay na kami ang responsable para sa mga pag-backup, bagama't mayroon silang sariling system administrator sa mga tauhan. Database ng Client-server, MS SQL bilang isang DBMS. Isang medyo karaniwang sitwasyon, ngunit mayroon pa ring isang nuance: ang pangunahing base ay medyo malaki, ngunit ang buwanang pagtaas ay napakaliit. Iyon ay, ang database ay naglalaman ng maraming makasaysayang data. Isinasaalang-alang ang feature na ito, nag-set up ako ng mga backup na plano sa pagpapanatili tulad ng sumusunod: sa unang Sabado ng bawat buwan isang buong backup ang ginawa, medyo mabigat ito, pagkatapos ay isang differential copy ang ginawa tuwing gabi - medyo maliit na volume, at isang kopya. ng log ng transaksyon bawat oras. Bukod dito, ang mga buo at naiibang kopya ay hindi lamang nakopya sa isang mapagkukunan ng network, ngunit na-upload din sa aming FTP server. Ito ay isang ipinag-uutos na kinakailangan kapag nagbibigay ng serbisyong ito.

Ang lahat ng ito ay matagumpay na na-configure, inilagay sa operasyon at sa pangkalahatan ay nagtrabaho nang walang mga pagkabigo.

Ngunit makalipas ang ilang buwan, nagbago ang system administrator sa organisasyong ito. Ang bagong system administrator ay nagsimulang unti-unting muling itayo ang IT infrastructure ng kumpanya alinsunod sa mga modernong uso. Sa partikular, lumitaw ang virtualization, mga istante ng disk, na-block ang pag-access sa lahat ng dako at lahat, atbp., na sa pangkalahatang kaso, siyempre, ay hindi maaaring magalak. Ngunit ang mga bagay ay hindi palaging maayos para sa kanya; madalas na may mga problema sa pagganap ng 1C, na nagdulot ng ilang hindi pagkakasundo at hindi pagkakaunawaan sa aming suporta. Gayundin, dapat tandaan na ang aming relasyon sa kanya sa pangkalahatan ay medyo malamig at medyo pilit, na nagpapataas lamang ng antas ng pag-igting sa kaganapan ng anumang mga problema na lumitaw.

Ngunit isang umaga, lumabas na hindi available ang server ng kliyenteng ito. Tumawag ako sa administrator ng system upang malaman kung ano ang nangyari at natanggap ko bilang isang sagot tulad ng "Nag-crash ang aming server, ginagawa namin ito, hindi sa iyo." Buti na lang nagtratrabaho sila. Nangangahulugan ito na ang sitwasyon ay nasa ilalim ng kontrol. Pagkatapos ng tanghalian, tumawag ulit ako, at sa halip na iritasyon, pagod at kawalang-interes na ang nararamdaman ko sa boses ng admin. Sinusubukan kong malaman kung ano ang nangyari at mayroon ba tayong magagawa upang matulungan? Bilang resulta ng pag-uusap, lumitaw ang mga sumusunod:

Inilipat niya ang server sa isang bagong sistema ng imbakan na may bagong binuong pagsalakay. Ngunit may nangyaring mali at makalipas ang ilang araw ay ligtas na bumagsak ang raid na ito. Kung nasunog ang controller o may nangyari sa mga disk, hindi ko eksaktong matandaan, ngunit ang lahat ng impormasyon ay hindi na mababawi. At ang pangunahing bagay ay ang mapagkukunan ng network na may mga backup ay napunta din sa parehong hanay ng disk sa panahon ng iba't ibang paglilipat. Ibig sabihin, parehong ang produktibong database mismo at lahat ng backup na kopya nito ay nawala. At hindi malinaw kung ano ang gagawin ngayon.

Huminahon ka, sabi ko. Nasa amin ang iyong panggabing backup. Bilang tugon, nagkaroon ng katahimikan, kung saan napagtanto ko na nailigtas ko lang ang buhay ng isang tao. Nagsisimula kaming talakayin kung paano ilipat ang kopyang ito sa isang bago, bagong naka-deploy na server. Ngunit dito rin lumitaw ang isang problema.

Tandaan noong sinabi kong medyo malaki ang buong backup? It was not for nothing na ginawa ko ito minsan sa isang buwan tuwing Sabado. Ang katotohanan ay ang kumpanya ay isang maliit na halaman, na matatagpuan malayo sa labas ng lungsod at ang kanilang Internet ay napaka-so-so. Pagsapit ng Lunes ng umaga, ibig sabihin, sa katapusan ng linggo, halos hindi na nai-upload ang kopyang ito sa aming FTP server. Ngunit walang paraan upang maghintay ng isa o dalawang araw para mag-load ito sa kabilang direksyon. Matapos ang ilang hindi matagumpay na pagtatangka na ilipat ang file, kinuha ng administrator ang hard drive nang direkta mula sa bagong server, nakakita ng isang kotse na may driver sa isang lugar at mabilis na sumugod sa aming opisina, sa kabutihang palad ay nasa parehong lungsod pa rin kami.

Habang nakatayo sila sa aming server room at naghihintay na makopya ang mga file, nagkita kami sa unang pagkakataon, kumbaga, β€œsa personal,” uminom ng isang tasa ng kape, at nag-usap sa isang impormal na setting. Nakiramay ako sa kanyang kalungkutan at pinabalik siya na may buong turnilyo ng mga backup, nagmamadaling ibinalik ang natigil na trabaho ng kumpanya.

Kasunod nito, ang lahat ng aming mga kahilingan sa departamento ng IT ay nalutas nang napakabilis at wala nang mga hindi pagkakasundo na lumitaw.

Makipag-ugnayan sa iyong system administrator

Minsan, sa napakahabang panahon, hindi ako makapag-publish ng 1C para sa web access sa pamamagitan ng IIS para sa isang kliyente. Tila isang ordinaryong gawain, ngunit walang paraan upang mapatakbo ang lahat. Nakilahok ang mga lokal na administrator ng system at sinubukan ang iba't ibang mga setting at configuration file. Karaniwang ayaw gumana ng 1C sa web sa anumang paraan. May mali, alinman sa mga patakaran sa seguridad ng domain, o sa lokal na sopistikadong firewall, o alam ng Diyos kung ano pa. Sa Nth iteration, pinadalhan ako ng admin ng link na may mga salitang:

- Subukang muli gamit ang mga tagubiling ito. Ang lahat ay inilarawan doon nang detalyado. Kung hindi ito gumana, sumulat sa may-akda ng site na ito, baka makatulong siya.
"Hindi," sabi ko, "hindi makakatulong."
- Bakit?
β€” Ako ang may-akda ng site na ito... (

Bilang resulta, inilunsad namin ito sa Apache nang walang anumang problema. Ang IIS ay hindi kailanman natalo.

Isang antas na mas malalim

Nagkaroon kami ng kliyente - isang maliit na negosyo sa pagmamanupaktura. Mayroon silang server, isang uri ng "classic" 3 sa 1: terminal server + application server + database server. Nagtrabaho sila sa ilang configuration na partikular sa industriya batay sa UPP, mayroong humigit-kumulang 15-20 user, at ang pagganap ng system, sa prinsipyo, ay angkop sa lahat.

Sa paglipas ng panahon, ang lahat ay gumagana nang higit pa o hindi gaanong matatag. Ngunit pagkatapos ay nagpataw ang Europa ng mga parusa laban sa Russia, bilang isang resulta kung saan ang mga Ruso ay nagsimulang bumili ng pangunahin na mga produktong gawa sa loob ng bansa, at ang negosyo para sa kumpanyang ito ay mabilis na umakyat. Ang bilang ng mga gumagamit ay tumaas sa 50-60 katao, isang bagong sangay ang binuksan, at ang daloy ng dokumento ay tumaas nang naaayon. At ngayon ang kasalukuyang server ay hindi na makayanan ang tumaas na pag-load, at ang 1C ay nagsimula, tulad ng sinasabi nila, upang "pabagal". Sa mga peak hours, ang mga dokumento ay naproseso sa loob ng ilang minuto, naganap ang mga error sa pagharang, ang mga form ay natagalan upang mabuksan, at ang buong iba pang palumpon ng mga kaugnay na serbisyo. Inalis ng lokal na administrator ng system ang lahat ng mga problema, na nagsasabing, "Ito ang iyong 1C, malalaman mo ito." Paulit-ulit naming iminungkahi ang pagsasagawa ng performance audit ng system, ngunit hindi ito dumating sa audit mismo. Ang kliyente ay humingi lamang ng mga rekomendasyon kung paano ayusin ang mga problema.

Buweno, naupo ako at nagsulat ng isang medyo mahabang liham tungkol sa pangangailangan na paghiwalayin ang mga tungkulin ng terminal server at ang application server sa DBMS (na, sa prinsipyo, maraming beses na nating sinabi noon). Sumulat ako tungkol sa DFSS sa mga terminal server, tungkol sa Shared Memory, nagbigay ng mga link sa mga authoritative source, at nagmungkahi pa ng ilang opsyon para sa equipment. Ang liham na ito ay nakarating sa mga may kapangyarihan sa kumpanya, bumalik sa departamento ng IT na may mga resolusyon na "Ipatupad" at ang yelo sa pangkalahatan ay nasira.

Pagkaraan ng ilang oras, ipinapadala sa akin ng admin ang IP address ng bagong server at mga kredensyal sa pag-log in. Sinabi niya na ang mga bahagi ng MS SQL at 1C server ay naka-deploy doon, at ang mga database ay kailangang ilipat, ngunit sa ngayon lamang sa DBMS server, dahil may ilang mga problema na lumitaw sa mga 1C key.

Pumasok ako, sa katunayan, lahat ng mga serbisyo ay tumatakbo, ang server ay hindi masyadong malakas, ngunit ok, sa tingin ko ito ay mas mahusay kaysa sa wala. Ililipat ko ang mga database sa ngayon upang kahit papaano ay mapawi ang kasalukuyang server. Nakumpleto ko ang lahat ng paglilipat sa napagkasunduang oras, ngunit hindi nagbago ang sitwasyon - pareho pa rin ang mga problema sa pagganap. Ito ay kakaiba, siyempre, mabuti, irehistro natin ang mga database sa 1C cluster at makikita natin.

Lumipas ang ilang araw, hindi nailipat ang mga susi. Nagtataka ako kung ano ang problema, ang lahat ay tila simple - alisin ito sa isang server, isaksak ito sa isa pa, i-install ang driver at tapos ka na. Tumugon ang admin sa pamamagitan ng pag-aalinlangan at pagsasabi ng tungkol sa pagpapasa ng port, isang virtual server, at iba pa.

Hmm... Virtual server? Tila walang anumang virtualization at wala pang nangyari... Naaalala ko ang isang medyo kilalang problema sa imposibilidad ng pagpapasa ng 1C server key sa isang virtual machine sa Hyper-V sa Windows Server 2008. At dito nagsimulang mabuo ang ilang mga hinala sa akin...

Binuksan ko ang manager ng server - Mga Tungkulin - may lumitaw na bagong tungkulin - Hyper-V. Pumunta ako sa Hyper-V manager, tingnan ang isang virtual machine, kumonekta... At sa katunayan... Ang aming bagong database server...

E ano ngayon? Ang mga tagubilin ng mga awtoridad at ang aking mga rekomendasyon ay natupad, ang mga tungkulin ay pinaghiwalay. Maaaring isara ang gawain.

Pagkaraan ng ilang oras, nangyari ang krisis ngayon, kinailangang isara ang bagong sangay, nabawasan ang pag-load, at ang pagganap ng system ay naging higit o hindi gaanong matitiis.

Well, siyempre, hindi nila maipasa ang server key sa virtual machine. Bilang isang resulta, ang lahat ay naiwan bilang ay: terminal server + 1C cluster sa isang pisikal na makina, database server doon sa isang virtual isa.

At magiging maganda kung ito ay isang uri ng opisina ng sharashkin. Kaya hindi. Isang kilalang kumpanya na ang mga produkto ay malamang na alam mo at nakita mo na sa mga nauugnay na departamento ng lahat ng Lentas at Auchan.

Iskedyul ng bakasyon sa hard drive

Isang malaking holding company na may ambisyosong plano na sakupin ang mundo ay muling bumili ng isang maliit na kumpanya na may layuning isama ito sa mega-corporation nito. Sa lahat ng mga dibisyon ng hawak na ito, ang mga gumagamit ay nagtatrabaho sa kanilang sariling mga database, ngunit may magkaparehong pagsasaayos. At kaya nagsimula kami ng isang maliit na proyekto para magsama ng bagong unit sa sistemang ito.

Una sa lahat, kinakailangan na mag-deploy ng mga database ng produksyon at pagsubok. Natanggap ng developer ang data ng koneksyon, nag-log in sa server, nakikita ang MS SQL na naka-install, 1C server, nakakakita ng 2 lohikal na drive: drive "C" na may kapasidad na 250 gigabytes at drive "D" na may kapasidad na 1 terabyte. Buweno, ang "C" ay ang sistema, ang "D" ay para sa data, ang developer ay lohikal na nagpapasya at nag-deploy ng lahat ng mga database doon. Nag-set up pa ako ng mga plano sa pagpapanatili, kasama ang backup, kung sakali (kahit na hindi kami mananagot para dito). Totoo, idinagdag dito ang mga backup sa "D". Sa hinaharap, binalak itong muling i-configure sa ilang hiwalay na mapagkukunan ng network.

Nagsimula ang proyekto, nagbigay ng pagsasanay ang mga consultant kung paano magtrabaho sa bagong sistema, inilipat ang mga natira, ilang menor de edad na pagpapabuti ang ginawa, at nagsimulang magtrabaho ang mga user sa bagong base ng impormasyon.

Maayos ang takbo ng lahat hanggang isang Lunes ng umaga nang matuklasan na nawawala ang database disk. Walang "D" sa server at iyon lang.

Ang karagdagang pagsisiyasat ay nagsiwalat nito: ang "server" na ito ay sa katunayan ang work computer ng isang lokal na administrator ng system. Totoo, mayroon pa itong server OS. Ang personal na USB drive ng admin na ito ay nakasaksak sa server. At kaya nagbakasyon ang administrator, dala ang kanyang tornilyo, na may layuning maglagay ng mga pelikula dito para sa paglalakbay.

Salamat sa Diyos, hindi niya pinamamahalaang tanggalin ang mga file ng database at pinamamahalaang ibalik ang produktibong database.

Kapansin-pansin na sa pangkalahatan ay nasiyahan ang lahat sa pagganap ng system na matatagpuan sa isang USB drive. Walang nagreklamo tungkol sa anumang hindi kasiya-siyang pagganap ng 1C. Nang maglaon lamang nagsimula ang paghawak ng isang mega-proyekto upang ilipat ang lahat ng mga database ng impormasyon sa isang solong sentralisadong site na may mga super-server, mga sistema ng imbakan para sa isang milyong+ rubles, mga sopistikadong hypervisors at hindi mabata na 1C preno sa lahat ng mga sangay.

Ngunit iyon ay isang ganap na naiibang kuwento ...

Pinagmulan: www.habr.com

Magdagdag ng komento