Tutti gli sviluppatori 1C in un modo o nell'altro interagiscono strettamente con i servizi IT e direttamente con gli amministratori di sistema. Ma questa interazione non sempre avviene senza intoppi. Vorrei raccontarvi alcune storie divertenti a riguardo.
Canale di comunicazione ad alta velocità
La maggior parte dei nostri clienti sono grandi aziende con i propri grandi dipartimenti IT. E gli specialisti del cliente sono generalmente responsabili delle copie di backup dei database di informazioni. Ma ci sono anche organizzazioni relativamente piccole. Soprattutto per loro abbiamo un servizio in base al quale ci facciamo carico di tutte le questioni relative al backup di tutto 1C. Questa è l’azienda di cui parleremo in questa storia.
Un nuovo cliente è arrivato per supportare 1C e, tra le altre cose, il contratto includeva una clausola secondo cui eravamo responsabili dei backup, sebbene avessero un proprio amministratore di sistema nello staff. Database client-server, MS SQL come DBMS. Una situazione abbastanza standard, ma c'era ancora una sfumatura: la base principale era piuttosto ampia, ma l'aumento mensile era molto piccolo. Cioè, il database conteneva molti dati storici. Tenendo conto di questa caratteristica, ho impostato i piani di manutenzione del backup nel modo seguente: il primo sabato di ogni mese veniva effettuato un backup completo, piuttosto pesante, poi ogni notte veniva effettuata una copia differenziale - un volume relativamente piccolo, e una copia del registro delle transazioni ogni ora. Inoltre, le copie complete e differenziali non sono state solo copiate su una risorsa di rete, ma anche caricate sul nostro server FTP. Questo è un requisito obbligatorio quando si fornisce questo servizio.
Tutto ciò è stato configurato con successo, messo in funzione e generalmente ha funzionato senza guasti.
Ma pochi mesi dopo, l'amministratore di sistema di questa organizzazione è cambiato. Il nuovo amministratore di sistema ha iniziato a ricostruire gradualmente l’infrastruttura IT dell’azienda secondo le tendenze moderne. In particolare, è apparsa la virtualizzazione, gli scaffali dei dischi, l'accesso è stato bloccato ovunque e tutto, ecc., Il che, nel caso generale, ovviamente, non può che rallegrarsi. Ma per lui le cose non sono sempre andate bene: spesso si sono verificati problemi con l’esecuzione di 1C, che hanno causato disaccordi e incomprensioni con il nostro supporto. Inoltre va notato che il nostro rapporto con lui è stato generalmente piuttosto freddo e un po' teso, il che non ha fatto altro che aumentare il grado di tensione in caso di problemi.
Ma una mattina si è scoperto che il server di questo cliente non era disponibile. Ho chiamato l'amministratore di sistema per sapere cosa fosse successo e ho ricevuto come risposta qualcosa del tipo "Il nostro server si è bloccato, ci stiamo lavorando, non dipende da te". Beh, è un bene che funzionino. Ciò significa che la situazione è sotto controllo. Dopo pranzo richiamo di nuovo e invece dell’irritazione sento già stanchezza e apatia nella voce dell’amministratore. Sto cercando di capire cosa è successo e c'è qualcosa che possiamo fare per aiutare? Dal colloquio è emerso quanto segue:
Ha spostato il server su un nuovo sistema di archiviazione con un raid appena assemblato. Ma qualcosa è andato storto e pochi giorni dopo il raid è crollato in modo sicuro. Se il controller si è bruciato o se è successo qualcosa ai dischi, non ricordo esattamente, ma tutte le informazioni sono andate irrimediabilmente perse. E la cosa principale era che anche la risorsa di rete con i backup finiva sullo stesso array di dischi durante varie migrazioni. Cioè, sia il database produttivo stesso che tutte le sue copie di backup sono andate perdute. E non è chiaro cosa fare adesso.
Calmati, dico. Abbiamo il tuo backup notturno. In risposta c’è stato silenzio, grazie al quale ho capito che avevo appena salvato la vita a un uomo. Iniziamo a discutere su come trasferire questa copia su un nuovo server appena distribuito. Ma anche qui è sorto un problema.
Ricordi quando ho detto che il backup completo era piuttosto grande? Non per niente lo facevo una volta al mese, il sabato. Il fatto è che l'azienda era una piccola fabbrica, situata molto fuori città e la loro connessione Internet era molto così così. Lunedì mattina, cioè durante il fine settimana, questa copia è riuscita a malapena a essere caricata sul nostro server FTP. Ma non c'era modo di aspettare un giorno o due affinché si caricasse nella direzione opposta. Dopo diversi tentativi falliti di trasferire il file, l'amministratore ha estratto il disco rigido direttamente dal nuovo server, ha trovato un'auto con autista da qualche parte e si è precipitato velocemente nel nostro ufficio, fortunatamente siamo ancora nella stessa città.
Mentre erano nella nostra sala server e aspettavano che i file venissero copiati, ci siamo incontrati per la prima volta, per così dire, "di persona", abbiamo bevuto una tazza di caffè e abbiamo parlato in un ambiente informale. Ho simpatizzato con il suo dolore e l'ho rimandato indietro con un sacco di backup, ripristinando frettolosamente il lavoro interrotto dell'azienda.
Successivamente, tutte le nostre richieste al reparto IT sono state risolte molto rapidamente e non sono sorti più disaccordi.
Contatta l'amministratore di sistema
Una volta, per molto tempo, non sono riuscito a pubblicare 1C per l'accesso al Web tramite IIS per un client. Sembrava un compito normale, ma non c'era modo di far funzionare tutto. Gli amministratori di sistema locali sono stati coinvolti e hanno provato diverse impostazioni e file di configurazione. 1C sul web normalmente non voleva funzionare in alcun modo. C'era qualcosa che non andava, o con le politiche di sicurezza del dominio, o con il sofisticato firewall locale, o Dio solo sa cos'altro. All'ennesima iterazione, l'amministratore mi invia un collegamento con le parole:
- Riprova utilizzando queste istruzioni. Tutto è descritto lì in modo abbastanza dettagliato. Se non funziona, scrivi all’autore di questo sito, forse può aiutarti.
"No", dico, "non aiuterà".
- Perché no?
— Sono l'autore di questo sito... (
Di conseguenza, l'abbiamo lanciato su Apache senza problemi. IIS non è mai stato sconfitto.
Un livello più profondo
Avevamo un cliente: una piccola impresa manifatturiera. Avevano un server, una sorta di “classico” 3 in 1: terminal server + application server + database server. Lavoravano in una configurazione specifica del settore basata su UPP, c'erano circa 15-20 utenti e le prestazioni del sistema, in linea di principio, erano adatte a tutti.
Col passare del tempo, tutto ha funzionato più o meno stabilmente. Ma poi l'Europa ha imposto sanzioni contro la Russia, a seguito delle quali i russi hanno iniziato ad acquistare principalmente prodotti di produzione nazionale, e gli affari di questa azienda sono aumentati notevolmente. Il numero di utenti è aumentato a 50-60 persone, è stata aperta una nuova filiale e il flusso di documenti è aumentato di conseguenza. E ora il server attuale non è più in grado di far fronte al carico notevolmente aumentato e 1C ha iniziato, come si suol dire, a "rallentare". Nelle ore di punta i documenti venivano elaborati per diversi minuti, si verificavano errori di blocco, l'apertura dei moduli impiegava molto tempo e tutto il resto dei servizi correlati. L'amministratore di sistema locale ha spazzato via tutti i problemi, dicendo: "Questo è il tuo 1C, lo capirai". Abbiamo più volte proposto di effettuare un controllo di gestione del sistema, ma non si è mai arrivati all'audit vero e proprio. Il cliente ha semplicemente chiesto consigli su come risolvere i problemi.
Ebbene, mi sono seduto e ho scritto una lettera piuttosto lunga sulla necessità di separare i ruoli del terminal server e dell'application server con il DBMS (cosa che, in linea di principio, abbiamo già detto molte volte). Ho scritto di DFSS sui server terminali, di memoria condivisa, ho fornito collegamenti a fonti autorevoli e ho persino suggerito alcune opzioni per le apparecchiature. Questa lettera è arrivata ai vertici dell'azienda, è tornata al dipartimento IT con le risoluzioni "Implementare" e il ghiaccio è stato generalmente rotto.
Dopo qualche tempo, l'amministratore mi invia l'indirizzo IP del nuovo server e le credenziali di accesso. Dice che lì vengono utilizzati i componenti server MS SQL e 1C e che i database devono essere trasferiti, ma per ora solo sul server DBMS, poiché con le chiavi 1C sono sorti alcuni problemi.
Sono entrato, infatti tutti i servizi erano attivi, il server non era molto potente, ma ok, penso sia meglio di niente. Per ora trasferirò i database per alleggerire in qualche modo il server attuale. Ho completato tutti i trasferimenti all'orario concordato, ma la situazione non è cambiata: sempre gli stessi problemi di prestazioni. È strano, ovviamente, beh, registriamo i database nel cluster 1C e vedremo.
Passano diversi giorni, le chiavi non sono state consegnate. Mi chiedo quale sia il problema, sembra tutto semplice: estrailo da un server, collegalo a un altro, installa il driver e il gioco è fatto. L'amministratore risponde agitandosi e dicendo qualcosa sul port forwarding, un server virtuale e così via.
Hmm... Server virtuale? Sembra che non ci sia mai stata virtualizzazione e non ce ne sono mai state... Ricordo un problema abbastanza noto con l'impossibilità di inoltrare una chiave server 1C a una macchina virtuale su Hyper-V in Windows Server 2008. E qui cominciano a formarsi in me alcuni sospetti...
Apro il server manager - Ruoli - è apparso un nuovo ruolo - Hyper-V. Vado al gestore Hyper-V, vedo una macchina virtuale, mi connetto... E infatti... Il nostro nuovo server database...
E allora? Le istruzioni delle autorità e le mie raccomandazioni sono state eseguite, i ruoli sono stati separati. L'attività può essere chiusa.
Dopo un po' di tempo, è arrivata la crisi, la nuova filiale ha dovuto essere chiusa, il carico è diminuito e le prestazioni del sistema sono diventate più o meno tollerabili.
Ovviamente non potevano inoltrare la chiave del server alla macchina virtuale. Di conseguenza, tutto è rimasto così com'è: server terminal + cluster 1C su una macchina fisica, server database lì su una macchina virtuale.
E sarebbe bello se questo fosse una specie di ufficio di Sharashkin. Quindi no. Una nota azienda i cui prodotti probabilmente conoscete e avete visto nei reparti competenti di tutti i Lenta e Auchan.
Programma delle vacanze del disco rigido
Una grande holding con ambiziosi progetti di conquista del mondo ha acquistato ancora una volta una piccola azienda con l'obiettivo di includerla nella sua mega-corporazione. In tutte le divisioni di questa azienda, gli utenti lavorano nei propri database, ma con una configurazione identica. E così abbiamo avviato un piccolo progetto per includere una nuova unità in questo sistema.
Innanzitutto è necessario implementare database di produzione e di test. Lo sviluppatore ha ricevuto i dati di connessione, accede al server, vede MS SQL installato, server 1C, vede 2 unità logiche: unità “C” con una capacità di 250 gigabyte e unità “D” con una capacità di 1 terabyte. Bene, "C" è il sistema, "D" è per i dati, lo sviluppatore decide logicamente e distribuisce lì tutti i database. Ho anche impostato piani di manutenzione, incluso il backup, per ogni evenienza (anche se non ne siamo responsabili). È vero, i backup sono stati aggiunti qui in "D". In futuro, è stato pianificato di riconfigurarlo su una risorsa di rete separata.
Il progetto è iniziato, i consulenti hanno fornito formazione su come lavorare nel nuovo sistema, gli avanzi sono stati trasferiti, sono stati apportati alcuni miglioramenti minori e gli utenti hanno iniziato a lavorare nella nuova base di informazioni.
Tutto andava bene finché un lunedì mattina si scoprì che mancava il disco del database. Semplicemente non c'è alcuna "D" sul server e basta.
Ulteriori indagini hanno rivelato questo: questo “server” era in realtà il computer di lavoro di un amministratore di sistema locale. È vero, aveva ancora un sistema operativo server. L'unità USB personale di questo amministratore è stata collegata al server. E così l'amministratore andò in vacanza, portando con sé la sua vita, con l'obiettivo di caricarci dentro dei film per il viaggio.
Grazie a Dio non è riuscito a eliminare i file del database ed è riuscito a ripristinare il database produttivo.
È interessante notare che tutti erano generalmente soddisfatti delle prestazioni del sistema situato su un'unità USB. Nessuno si è lamentato di eventuali prestazioni insoddisfacenti di 1C. Solo più tardi l'azienda ha avviato un megaprogetto per trasferire tutti i database di informazioni in un unico sito centralizzato con superserver, sistemi di archiviazione per oltre un milione di rubli, sofisticati hypervisor e insopportabili freni 1C in tutte le filiali.
Ma questa è una storia completamente diversa ...
Fonte: habr.com