Wszyscy programiści 1C w taki czy inny sposób ściśle współdziałają z usługami IT i bezpośrednio z administratorami systemu. Ale ta interakcja nie zawsze przebiega gładko. Chciałbym opowiedzieć kilka zabawnych historii na ten temat.
Kanał szybkiej komunikacji
Większość naszych klientów to duże holdingi posiadające własne, duże działy IT. Specjaliści klienta są zwykle odpowiedzialni za kopie zapasowe informacyjnych baz danych. Ale są też stosunkowo małe organizacje. Specjalnie dla nich mamy usługę, zgodnie z którą bierzemy na siebie wszystkie kwestie związane z tworzeniem kopii zapasowych wszystkiego 1C. To właśnie o tej firmie będziemy mówić w tej historii.
Do wsparcia 1C przyszedł nowy klient i między innymi w umowie była klauzula, że to my jesteśmy odpowiedzialni za kopie zapasowe, mimo że zatrudniał on własnego administratora systemu. Baza danych klient-serwer, MS SQL jako DBMS. Sytuacja dość standardowa, ale był jeszcze jeden niuans: baza główna była dość duża, ale miesięczny przyrost był bardzo niewielki. Oznacza to, że baza danych zawierała wiele danych historycznych. Biorąc pod uwagę tę funkcję, ułożyłem plany konserwacji kopii zapasowych w następujący sposób: w pierwszą sobotę każdego miesiąca wykonywano pełną kopię zapasową, była ona dość ciężka, następnie co noc wykonywano kopię różnicową - stosunkowo niewielki wolumen, a następnie kopię dziennika transakcji co godzinę. Co więcej, kopie pełne i różnicowe nie tylko zostały skopiowane do zasobu sieciowego, ale także dodatkowo przesłane na nasz serwer FTP. Jest to wymóg obowiązkowy przy świadczeniu tej usługi.
Wszystko to zostało pomyślnie skonfigurowane, uruchomione i ogólnie działało bezawaryjnie.
Ale kilka miesięcy później zmienił się administrator systemu w tej organizacji. Nowy administrator systemu przystąpił do stopniowej przebudowy infrastruktury informatycznej firmy zgodnie ze współczesnymi trendami. W szczególności pojawiła się wirtualizacja, półki dyskowe, dostęp został zablokowany wszędzie i wszystko itp., Co w ogólnym przypadku oczywiście nie może się nie cieszyć. Jednak nie zawsze wszystko szło mu gładko; często pojawiały się problemy z występami 1C, co powodowało pewne nieporozumienia i nieporozumienia z naszym wsparciem. Warto też zaznaczyć, że nasze relacje z nim były generalnie dość chłodne i nieco napięte, co tylko zwiększało stopień napięcia w przypadku pojawienia się jakichkolwiek problemów.
Jednak pewnego ranka okazało się, że serwer tego klienta był niedostępny. Zadzwoniłem do administratora systemu, aby dowiedzieć się, co się stało, i otrzymałem odpowiedź w stylu: „Nasz serwer się zawiesił, pracujemy nad tym, nie zależy to od Ciebie”. No to dobrze, że działają. Oznacza to, że sytuacja jest pod kontrolą. Po obiedzie dzwonię ponownie i zamiast irytacji, już czuję zmęczenie i apatię w głosie administratora. Próbuję dowiedzieć się, co się stało i czy możemy w czymś pomóc? W wyniku rozmowy wyszło co następuje:
Przeniósł serwer do nowego systemu przechowywania danych z nowo złożonym raidem. Ale coś poszło nie tak i kilka dni później ten nalot bezpiecznie upadł. Czy spalił się kontroler, czy coś się stało z dyskami, nie pamiętam dokładnie, ale wszystkie informacje zostały bezpowrotnie utracone. A najważniejsze było to, że zasób sieciowy z kopiami zapasowymi również podczas różnych migracji trafiał na tę samą macierz dyskową. Oznacza to, że zarówno sama produktywna baza danych, jak i wszystkie jej kopie zapasowe zostały utracone. I nie jest jasne, co teraz zrobić.
Uspokój się, mówię. Mamy Twoje nocne wsparcie. W odpowiedzi zapadła cisza, po której zdałam sobie sprawę, że właśnie uratowałam życie człowieka. Zaczynamy omawiać sposób przeniesienia tej kopii na nowy, nowo wdrożony serwer. Ale i tutaj pojawił się problem.
Pamiętasz, jak mówiłem, że pełna kopia zapasowa jest dość duża? Nie bez powodu robiłem to raz w miesiącu w soboty. Faktem jest, że firma była małym zakładem, który znajdował się daleko od miasta, a ich Internet był bardzo sobie taki sobie. Do poniedziałku rano, czyli przez weekend, ledwo udało się przesłać tę kopię na nasz serwer FTP. Ale nie było sposobu, aby poczekać dzień lub dwa, aż załaduje się w przeciwnym kierunku. Po kilku nieudanych próbach przesłania pliku, administrator wyjął dysk bezpośrednio z nowego serwera, znalazł gdzieś samochód z kierowcą i szybko pobiegł do naszego biura, na szczęście wciąż jesteśmy w tym samym mieście.
Kiedy oni stali w naszej serwerowni i czekali na skopiowanie plików, spotkaliśmy się po raz pierwszy, że tak powiem, „osobiście”, wypiliśmy kawę i porozmawialiśmy w nieformalnej atmosferze. Współczułem mu w żałobie i odesłałem go z powrotem z pełną śrubą kopii zapasowych, pospiesznie przywracając przerwaną pracę firmy.
Następnie wszystkie nasze prośby kierowane do działu IT zostały rozpatrzone bardzo szybko i nie było już więcej nieporozumień.
Skontaktuj się z administratorem systemu
Kiedyś przez bardzo długi czas nie mogłem opublikować 1C dla dostępu do Internetu przez IIS dla jednego klienta. Wydawało się to zwyczajnym zadaniem, ale nie było sposobu, aby wszystko uruchomić. Zaangażowali się w to lokalni administratorzy systemu i wypróbowali różne ustawienia i pliki konfiguracyjne. 1C w sieci zwykle nie chciało w żaden sposób pracować. Coś było nie tak albo z polityką bezpieczeństwa domeny, albo z lokalną, wyrafinowaną zaporą ogniową, albo Bóg jeden wie, co jeszcze. W N-tej iteracji administrator wysyła mi link ze słowami:
- Spróbuj ponownie, korzystając z tych instrukcji. Wszystko jest tam dość szczegółowo opisane. Jeśli to nie zadziała, napisz do autora tej strony, może będzie mógł pomóc.
„Nie” – mówię – „to nie pomoże”.
- Dlaczego?
— Jestem autorem tej strony... (
W rezultacie uruchomiliśmy go na Apache bez żadnych problemów. IIS nigdy nie został pokonany.
Jeden poziom głębiej
Mieliśmy klienta - małe przedsiębiorstwo produkcyjne. Mieli serwer, coś w rodzaju „klasycznego” 3 w 1: serwer terminali + serwer aplikacji + serwer bazy danych. Pracowali w jakiejś branżowej konfiguracji opartej na UPP, było około 15-20 użytkowników, a wydajność systemu w zasadzie odpowiadała każdemu.
Z biegiem czasu wszystko działało mniej więcej stabilnie. Ale potem Europa nałożyła sankcje na Rosję, w wyniku czego Rosjanie zaczęli kupować głównie produkty krajowe, a biznes tej firmy gwałtownie wzrósł. Liczba użytkowników wzrosła do 50-60 osób, otwarto nowy oddział i odpowiednio wzrósł obieg dokumentów. A teraz obecny serwer nie był już w stanie poradzić sobie z gwałtownie zwiększonym obciążeniem, a 1C zaczął, jak mówią, „zwalniać”. W godzinach szczytu dokumenty były przetwarzane przez kilka minut, pojawiały się błędy w blokowaniu, długo otwierały się formularze i cały wachlarz usług z tym związanych. Lokalny administrator systemu odrzucił wszystkie problemy, mówiąc: „To jest twój 1C, rozwiążesz to”. Wielokrotnie proponowaliśmy przeprowadzenie audytu działania systemu, jednak nigdy nie doszło do samego audytu. Klient po prostu poprosił o zalecenia dotyczące rozwiązania problemów.
No cóż, usiadłem i napisałem dość długi list o konieczności rozdzielenia roli serwera terminali i serwera aplikacji w SZBD (o czym w zasadzie mówiliśmy już wiele razy). Pisałem o DFSS na serwerach terminali, o pamięci współdzielonej, podałem linki do wiarygodnych źródeł, a nawet zasugerowałem pewne opcje sprzętu. List ten dotarł do osób sprawujących władzę w firmie, wrócił do działu IT z postanowieniami „Wdrażaj” i lody w zasadzie zostały przełamane.
Po pewnym czasie administrator przesyła mi adres IP nowego serwera i dane logowania. Mówi, że są tam wdrożone komponenty serwera MS SQL i 1C, a bazy danych muszą zostać przeniesione, ale na razie tylko na serwer DBMS, ponieważ pojawiły się pewne problemy z kluczami 1C.
Wszedłem, rzeczywiście wszystkie usługi działały, serwer nie był zbyt wydajny, ale ok, myślę, że lepsze to niż nic. Na razie przeniosę bazy danych, żeby w jakiś sposób odciążyć obecny serwer. Wszystkie przelewy zrealizowałem w ustalonym terminie, jednak sytuacja się nie zmieniła – nadal te same problemy z wydajnością. To oczywiście dziwne, cóż, zarejestrujmy bazy danych w klastrze 1C i zobaczymy.
Minęło kilka dni, klucze nie zostały przekazane. Zastanawiam się w czym tkwi problem, wszystko wydaje się proste - wyjmij z jednego serwera, podłącz do innego, zainstaluj sterownik i gotowe. Administrator odpowiada, kłócąc się i mówiąc coś o przekierowaniu portów, serwerze wirtualnym i tak dalej.
Hmm... Serwer wirtualny? Wydaje się, że wirtualizacji nigdy nie było i nie było... Pamiętam dość znany problem z niemożnością przekazania klucza serwera 1C na maszynę wirtualną na Hyper-V w Windows Server 2008. I tutaj zaczynają we mnie kiełkować pewne podejrzenia...
Otwieram menedżera serwerów - Role - pojawiła się nowa rola - Hyper-V. Wchodzę do menadżera Hyper-V, widzę jedną maszynę wirtualną, łączę się... I rzeczywiście... Nasz nowy serwer baz danych...
Więc co? Zalecenia władz i moje zalecenia zostały wykonane, role zostały rozdzielone. Zadanie można zamknąć.
Po pewnym czasie nastąpił obecny kryzys, trzeba było zamknąć nowy oddział, obciążenie spadło, a wydajność systemu stała się mniej więcej znośna.
Cóż, oczywiście nie mogli przekazać klucza serwera do maszyny wirtualnej. W rezultacie wszystko pozostało tak jak jest: serwer terminali + klaster 1C na maszynie fizycznej, serwer bazy danych tam na wirtualnym.
I byłoby miło, gdyby to było coś w rodzaju biura Sharashkina. Więc nie. Znana firma, której produkty zapewne znacie i widzieliście w odpowiednich działach wszystkich Lent i Auchanów.
Harmonogram wakacji na dysku twardym
Duży holding z ambitnymi planami przejęcia świata po raz kolejny kupił małą spółkę w celu włączenia jej do swojej megakorporacji. We wszystkich oddziałach tego holdingu użytkownicy pracują na własnych bazach danych, jednak z identyczną konfiguracją. Rozpoczęliśmy więc mały projekt mający na celu włączenie nowej jednostki do tego systemu.
Przede wszystkim konieczne jest wdrożenie produkcyjnych i testowych baz danych. Programista otrzymał dane połączenia, loguje się do serwera, widzi zainstalowany MS SQL, serwer 1C, widzi 2 dyski logiczne: dysk „C” o pojemności 250 gigabajtów i dysk „D” o pojemności 1 terabajta. Cóż, „C” to system, „D” to dane, programista logicznie decyduje i wdraża tam wszystkie bazy danych. Stworzyłem nawet plany konserwacji, obejmujące tworzenie kopii zapasowych, na wszelki wypadek (choć nie jesteśmy za to odpowiedzialni). To prawda, że \uXNUMXb\uXNUMXbdodano tutaj kopie zapasowe do „D”. W przyszłości planowano ponownie skonfigurować go na osobny zasób sieciowy.
Projekt się rozpoczął, konsultanci przeprowadzili szkolenia z pracy w nowym systemie, przeniesiono resztki, wprowadzono drobne usprawnienia, a użytkownicy rozpoczęli pracę w nowej bazie informacji.
Wszystko szło dobrze aż do pewnego poniedziałkowego poranka, kiedy odkryto, że brakuje dysku z bazą danych. Na serwerze po prostu nie ma „D” i tyle.
Dalsze dochodzenie ujawniło, co następuje: ten „serwer” był w rzeczywistości komputerem roboczym lokalnego administratora systemu. To prawda, że nadal miał serwerowy system operacyjny. Osobisty dysk USB tego administratora został podłączony do serwera. I tak administrator pojechał na wakacje, zabierając ze sobą swoją śrubę, aby wpompować w nią filmy na podróż.
Dzięki Bogu nie udało mu się usunąć plików bazy danych i udało się przywrócić produktywną bazę danych.
Warto zauważyć, że wszyscy byli ogólnie zadowoleni z wydajności systemu umieszczonego na dysku USB. Nikt nie skarżył się na niezadowalające działanie 1C. Dopiero później holding rozpoczął megaprojekt mający na celu przeniesienie wszystkich baz danych informacyjnych do jednej scentralizowanej lokalizacji z superserwerami, systemami przechowywania za ponad milion rubli, wyrafinowanymi hypervisorami i nieznośnymi hamulcami 1C we wszystkich oddziałach.
Ale to zupełnie inna historia...
Źródło: www.habr.com