1C'de şirketin çalışmalarını organize etmek için kendi geliştirmelerimizi yaygın olarak kullanıyoruz. Özellikle, . Belge yönetimine ek olarak (adından da anlaşılacağı gibi) aynı zamanda modern bir uygulamadır. -çok çeşitli işlevlere sahip sistem (Kurumsal İçerik Yönetimi - kurumsal içerik yönetimi) - posta, çalışanların çalışma takvimleri, kaynaklara ortak erişimin düzenlenmesi (örneğin, toplantı odalarının rezervasyonu), zaman takibi, kurumsal forum ve çok daha fazlası.
Binden fazla çalışan 1C'de belge yönetimini kullanıyor. Veritabanı şimdiden etkileyici hale geldi (11 milyar kayıt), bu da daha dikkatli bakım ve daha güçlü ekipman gerektirdiği anlamına geliyor.
Sistemimiz nasıl çalışıyor, veritabanını korurken ne gibi zorluklarla karşılaşıyoruz ve bunları nasıl çözüyoruz (MS SQL Server'ı DBMS olarak kullanıyoruz) - makalede size anlatacağız.
1C ürünlerini ilk kez okuyanlar için.
1C:Document Flow, iş uygulamaları geliştirmeye yönelik bir çerçeve olan 1C:Enterprise platformu temelinde uygulanan bir uygulama çözümüdür (konfigürasyon).
“1C: Document Flow 8” (DO olarak kısaltılır), bir kuruluştaki belgelerle çalışmayı otomatikleştirmenize olanak tanır. Çalışan etkileşiminin ana araçlarından biri e-postadır. DO, postaya ek olarak diğer sorunları da çözer:
- Zaman takibi
- Çalışan devamsızlık takibi
- Kuryeler/nakliye başvuruları
- Çalışanların çalışma takvimleri
- Yazışmaların kaydı
- Çalışan İletişim Bilgileri (Adres Defteri)
- Kurumsal forum
- Oda rezervasyonu
- Olay planlaması
- CRM
- Dosyalarla toplu çalışma (dosya sürümlerinin kaydedilmesiyle)
- vb
Doküman Yönetimine giriyoruz (yerel yürütülebilir uygulama) Windows, Linux, macOS'tan, (tarayıcılardan) ve - duruma bağlı olarak.
Ve Document Flow'a bağlı diğer ürünümüz sayesinde - – Messenger'ın işlevselliğini doğrudan Document Flow'da alıyoruz – sohbetler, sesli ve görüntülü aramalar (mobil istemciden de dahil olmak üzere artık özellikle önemli hale gelen grup aramaları dahil), hızlı dosya alışverişi ve bunu kolaylaştıran sohbet botları yazma yeteneği sistemle çalışıyor. Etkileşim Sistemini kullanmanın bir diğer avantajı (diğer mesajlaşma araçlarıyla karşılaştırıldığında), belirli Belge Akışı nesnelerine (belgeler, olaylar vb.) bağlı bağlamsal tartışmaları yürütebilme yeteneğidir. Yani Etkileşim Sistemi hedef uygulama ile derinlemesine entegredir ve sadece “ayrı bir buton” görevi görmez.
DO'muzdaki harf sayısı şimdiden 100 milyonu aştı ve genel olarak DBMS'de 11 milyardan fazla kayıt var. Toplamda, sistem neredeyse 30 TB depolama alanı kullanıyor: veritabanı hacmi 7,5 TB'dir, toplu çalışma dosyaları ayrı olarak depolanır ve 21 TB daha kaplar.
Daha spesifik rakamlardan bahsedecek olursak, şu anki harf ve dosya sayıları şöyle:
- Giden e-postalar – 14,7 milyon.
- Gelen mektuplar – 85,4 milyon.
- Dosya sürümleri – 70,8 milyon.
- Dahili belgeler – 30,6 bin.
DO'da posta ve dosyalardan daha fazlası vardır. Aşağıda diğer muhasebe nesnelerine ilişkin rakamlar verilmiştir:
- Toplantı odası rezervasyonu – 52
- Haftalık raporlar – 153
- Günlük raporlar – 628
- Onaylanan vizeler – 11
- Gelen belgeler – 79
- Giden belgeler – 28
- Kullanıcı çalışma takvimlerindeki etkinliklerle ilgili girişler – 168
- Kurye başvuruları – 21
- Karşı taraflar – 81
- Karşı taraflarla yapılan iş kayıtları – 45
- Karşı tarafların irtibat kişileri – 41
- Etkinlikler – 10
- Projeler – 6
- Çalışan görevleri – 245
- Forum gönderileri – 26
- Sohbet mesajları – 891 095
- İş süreçleri - 109 Çalışanlar arasındaki etkileşim, onay, yürütme, inceleme, kayıt, imzalama vb. süreçler aracılığıyla gerçekleşir. Süreçlerin süresini, döngü sayısını, katılımcı sayısını, geri dönüş sayısını, son tarih değişikliği taleplerinin sayısını ölçüyoruz. Ve bu bilgilerin, kuruluşta hangi süreçlerin gerçekleştiğini anlamak ve çalışanlar arasındaki işbirliğinin verimliliğini artırmak için analiz edilmesi çok faydalıdır.
Tüm bunları hangi ekipmanla işliyoruz?
Bu rakamlar etkileyici bir görev hacmine işaret ediyor, bu nedenle dahili iştiraklerin ihtiyaçlarına oldukça verimli ekipman tahsis etme ihtiyacıyla karşı karşıya kaldık. Şu anda özellikleri şu şekildedir: 38 çekirdek, 240 GB RAM, 26 TB disk. İşte sunucuların bir tablosu:
Gelecekte ekipmanın kapasitesini artırmayı planlıyoruz.
Sunucu yükünde işler nasıl gidiyor?
Ağ etkinliği bizim veya müşterilerimiz için hiçbir zaman sorun olmadı. Kural olarak, işlemci ve diskler zayıf noktadır, çünkü herkes zaten bellek eksikliğiyle nasıl başa çıkacağını biliyor. İşte Resource Monitor'den sunucularımızın ekran görüntüleri, bu da korkunç bir yükümüz olmadığını, çok mütevazı olduğunu gösteriyor.
Örneğin aşağıdaki ekran görüntüsünde CPU yükünün %23 olduğu bir SQL sunucusu görüyoruz. Ve bu çok iyi bir göstergedir (karşılaştırma için: yük% 70'e yaklaşırsa, büyük olasılıkla çalışanlar işte oldukça önemli yavaşlamalar gözlemleyecektir).
İkinci ekran görüntüsü, 1C:Enterprise platformunun çalıştığı uygulama sunucusunu gösterir; yalnızca kullanıcı oturumlarına hizmet eder. Burada işlemci yükü biraz daha yüksek - %38, sorunsuz ve sakin. Bir miktar disk yüklemesi var, ancak kabul edilebilir.
Üçüncü ekran görüntüsü başka bir 1C:Enterprise sunucusunu gösteriyor (ikincisi, kümede iki tane var). Yalnızca bir önceki kullanıcılara hizmet veriyor ve bunun üzerinde robotlar çalışıyor. Örneğin, posta alırlar, belgeleri yönlendirirler, veri alışverişinde bulunurlar, hakları hesaplarlar vb. Tüm bu arka plan faaliyetleri yaklaşık 90-100 arka plan işi gerçekleştirir. Ve bu sunucu çok yoğun bir şekilde yüklendi - %88. Ancak bu insanları etkilemez ve Doküman Yönetiminin yapması gereken tüm otomasyonu tam olarak uygular.
Performansı ölçecek ölçütler nelerdir?
Performans göstergelerini ölçmek ve çeşitli metrikleri hesaplamak için iştiraklerimizde yerleşik ciddi bir alt sistemimiz var. Hem şu anda hem de tarihsel açıdan sistemde neler olduğunu, neyin kötüye gittiğini, neyin iyiye gittiğini anlamak için bu gereklidir. İzleme araçları (metrikler ve zaman ölçümleri) "1C: Document Flow 8"in standart teslimatına dahildir. Metrikler uygulama sırasında özelleştirme gerektirir ancak mekanizmanın kendisi standarttır.
Metrikler, çeşitli iş göstergelerinin belirli zaman noktalarındaki ölçümleridir (örneğin, ortalama posta teslim süresi 10 dakikadır).
Metriklerden biri veritabanındaki aktif kullanıcı sayısını gösterir. Gün içerisinde ortalama 1000-1400 adet bulunmaktadır. Grafik, ekran görüntüsünün alındığı sırada veritabanında 2144 aktif kullanıcının bulunduğunu göstermektedir.
Bu tür 30'dan fazla eylem var, liste kesinti altında.Liste
- Giriş yapmak
- Oturumu Kapat
- Posta yükleniyor
- Bir nesnenin geçerliliğini değiştirme
- Erişim haklarını değiştirme
- Bir sürecin konusunu değiştirme
- Bir nesnenin çalışma grubunu değiştirme
- Kitin bileşimini değiştirme
- Bir dosyayı değiştirme
- Dosya içe aktarma
- Posta ile gönderme
- Dosyaları taşıma
- Bir görevi yönlendirme
- Elektronik imzanın imzalanması
- Ayrıntılara göre ara
- Tam metin araması
- Dosya alma
- Bir süreci kesintiye uğratmak
- Просмотр
- Şifre çözme
- Belge kaydı
- taramak
- Silme işleminin işareti kaldırılıyor
- Nesne Oluşturma
- Diske kaydetme
- Sürecin başlangıcı
- Kullanıcı günlüğü girişlerini silme
- Elektronik imzayı kaldırma
- Bir silme işareti ayarlama
- Şifreleme
- Bir klasörü dışa aktar
Geçen haftadan önceki hafta, ortalama kullanıcı etkinliğimiz bir buçuk kat arttı (grafikte kırmızıyla gösterilmiştir) - bunun nedeni çoğu çalışanın uzaktan çalışmaya geçmesidir (iyi bilinen olaylar nedeniyle). Ayrıca, çalışanlar cep telefonlarını aktif olarak kullanmaya başladıkça aktif kullanıcı sayısı 3 kat arttı (ekran görüntüsünde mavi renkle gösterilmiştir): her mobil istemci sunucuyla bir bağlantı oluşturur. Şu anda ortalama olarak her çalışanımızın sunucuya 2 bağlantısı bulunmaktadır.
Yöneticiler olarak bizim için bu, performans sorunlarına daha dikkatli yaklaşmamız ve işlerin daha da kötüye gidip gitmediğini görmemiz gerektiğinin bir işaretidir. Ama biz buna başka parametreler üzerinden bakıyoruz. Örneğin, dahili yönlendirme için posta teslim süresinin nasıl değiştiği (aşağıdaki ekran görüntüsünde mavi renkle gösterilmiştir). Bu seneye kadar dalgalı bir seyir izlediğini görüyoruz ama artık stabil. Bu bizim için sistemde her şeyin yolunda olduğunun göstergesi.
Bizim için uygulanan bir diğer ölçüm de posta sunucusundan mektupların indirilmesi için ortalama bekleme süresidir (ekran görüntüsünde kırmızıyla gösterilmiştir). Kabaca konuşursak, mektup çalışanımıza ulaşana kadar internette ne kadar süre dolaşacak? Ekran görüntüsü, bu sürenin de son zamanlarda hiçbir şekilde değişmediğini gösteriyor. İzole ani artışlar var - ancak bunlar gecikmelerle değil, posta sunucularında zaman kaybıyla ilişkili.
Veya, örneğin başka bir ölçüm (ekran görüntüsünde mavi renkle gösterilmiştir) – bir klasördeki harflerin güncellenmesi. Bir posta klasörünü açmak çok yaygın bir işlemdir ve hızlı bir şekilde yapılması gerekir. Ne kadar hızlı yapıldığını ölçüyoruz. Bu gösterge her müşteri için ölçülür. Hem şirketin genel resmini hem de örneğin bireysel bir çalışanın dinamiklerini görebilirsiniz. Ekran görüntüsü, bu yıla kadar metriğin dengesiz olduğunu, daha sonra bir takım iyileştirmeler yaptığımızı ve şimdi durumun daha da kötüye gitmediğini gösteriyor; grafik neredeyse düz.
Metrikler temel olarak bir yöneticinin sistemi izlemeye, sistemin davranışındaki herhangi bir değişikliğe hızlı bir şekilde yanıt vermeye yönelik bir aracıdır. Ekran görüntüsü yıla ait dahili bağlı kuruluş metriklerini gösterir. Grafiklerdeki sıçrama, bize şirket içi bağlı ortaklıklar geliştirme görevi verilmiş olmasından kaynaklanıyor.
İşte bazı ölçümlerin listesi (kesimin altında).
Metrikler
- Kullanıcı etkinliği
- Aktif Kullanıcılar
- Aktif süreçler
- Dosya sayısı
- Dosya boyutu (MB)
- Belge sayısı
- Alıcılara gönderilecek nesne sayısı
- Karşı taraf sayısı
- Tamamlanmamış görevler
- Son 10 dakika içinde posta sunucusundan e-postaların indirilmesi için ortalama bekleme süresi
- Harici veri arabelleği: dosya sayısı
- Geçerli tarihten itibaren gecikme sınırı
- Uzun kuyruk
- Operasyonel kuyruk
- Harici yönlendirmeye göre ham hesap yaşı
- Dahili yönlendirme kabul kuyruğu boyutu (uzun kuyruk)
- Dahili yönlendirme kabul kuyruğu boyutu (hızlı kuyruk)
- Dahili yönlendirme yoluyla posta teslim süresi (uzun kuyruk)
- Dahili yönlendirme yoluyla posta teslim süresi (hızlı kuyruk)
- Harici yönlendirme yoluyla posta teslim süresi (ortalama)
- Belge Sayısı Rezervasyon
- Belge sayısı Yokluk
- Belge sayısı “Karşı tarafla yapılan işin kaydı”
- Bir klasördeki Posta Güncelleme mektupları
- Posta Mektup kartı açma
- Posta Bir mektubu bir klasöre aktarma
- Posta Klasörler arasında gezinin
Sistemimiz günün her saatinde 150'den fazla göstergeyi ölçer ancak bunların tümü hızlı bir şekilde izlenemez. Bunlar daha sonra tarihsel bir bakış açısıyla işinize yarayabilir ve işiniz için en önemli olanlara odaklanabilirsiniz.
Örneğin uygulamaların birinde yalnızca 5 gösterge seçilmiştir. Müşteri, minimum gösterge seti oluşturmak için bir hedef belirledi, ancak aynı zamanda ana çalışma senaryolarını da kapsayacak şekilde. Kabul belgesine 150 göstergenin dahil edilmesi haksızlık olur, çünkü işletme içinde bile hangi göstergelerin kabul edilebilir olduğu konusunda anlaşmaya varmak zordur. Ve bu 5 göstergeyi biliyorlardı ve bunları yarışma belgelerine dahil ederek uygulama projesinin başlangıcından önce sisteme sunmuşlardı: bir kartı açma süresi en fazla 3 saniye, bir görevi no. 5 saniyeden fazla vb. İştiraklerimizde, müşterinin teknik spesifikasyonlarından orijinal talebi çok net bir şekilde yansıtan metriklerimiz vardı.
Ayrıca performans ölçümlerinin profil analizine de sahibiz. Performans göstergeleri, devam eden her işlemin (veritabanına mektup yazma, posta sunucusuna mektup gönderme vb.) süresinin kaydıdır. Bu yalnızca teknisyenler tarafından kullanılır. Programımızda birçok performans göstergesi biriktiriyoruz. Şu anda profillere bölünmüş yaklaşık 1500 anahtar işlemi ölçüyoruz.
Bizim için en önemli profillerden biri “Tüketici Bakış Açısından Postanın Temel Göstergelerinin Listesi”dir. Bu profil örneğin aşağıdaki göstergeleri içerir:
- Komutun yürütülmesi: Etikete göre seç
- Form açma: Liste Formu
- Komutun yürütülmesi: Klasöre göre seç
- Okuma alanında bir harfin görüntülenmesi
- Bir mektubu favori klasörünüze kaydetme
- Harfleri ayrıntılara göre arayın
- Bir mektup oluşturmak
Bazı iş göstergelerinin metriğinin çok büyük hale geldiğini görürsek (örneğin, belirli bir kullanıcıdan gelen mektuplar çok uzun süredir gelmeye başladı), bunu anlamaya başlarız ve teknik operasyonların süresini ölçmeye başlarız. “Posta sunucusundaki mektupları arşivleme” teknik bir operasyonumuz var - son dönemde bu işlemin süresinin aşıldığını görüyoruz. Bu işlem de diğer işlemlere ayrıştırılır - örneğin bir posta sunucusuyla bağlantı kurmak. Bir nedenden dolayı aniden çok büyüdüğünü görüyoruz (bir ay boyunca tüm ölçümlerimiz var - geçen hafta 10 milisaniye olduğunu ve şimdi 1000 milisaniye olduğunu karşılaştırabiliriz). Ve burada bir şeyin bozulduğunu anlıyoruz - onu düzeltmemiz gerekiyor.
Bu kadar büyük bir veri tabanını nasıl koruyabiliriz?
Dahili DO'muz gerçekten çalışan, yüksek yüklü bir projenin bir örneğidir. Veritabanının teknik özelliklerinden bahsedelim.
Büyük veritabanı tablolarını yeniden yapılandırmak ne kadar sürer?
SQL sunucusu periyodik bakım gerektirir, tabloları düzene sokar. İyi anlamda, bunun günde en az bir kez, hatta yüksek talep gören masalarda daha sık yapılması gerekir. Ancak veritabanı büyükse (ve kayıt sayımız zaten 11 milyarı aştıysa), o zaman onunla ilgilenmek kolay değil.
6 yıl önce masa düzenlemesi yapmıştık ama sonra o kadar zaman almaya başladı ki artık gece aralıklarına sığmaz hale geldik. Ve bu işlemler SQL sunucusuna ağır yük getirdiği için diğer kullanıcılara verimli bir şekilde hizmet veremez.
Bu nedenle artık çeşitli hileler kullanmak zorundayız. Örneğin bu prosedürleri tam veri setleri üzerinde gerçekleştiremiyoruz. Örnek 500000 satırını Güncelle prosedürüne başvurmanız gerekir - bu 14 dakika sürer. Tablodaki tüm verilere ilişkin istatistikleri güncellemez, ancak yarım milyon satırı seçer ve bunları, tablonun tamamı için kullandığı istatistikleri hesaplamak için kullanır. Bu bir varsayım, ancak bunu yapmak zorundayız çünkü belirli bir tablo için milyarlarca kaydın tamamına ilişkin istatistikleri toplamak kabul edilemeyecek kadar uzun bir zaman alacaktır.
Diğer bakım işlemlerini de kısmi hale getirerek optimize ettik.
Bir DBMS'nin bakımı genellikle karmaşık bir iştir. Çalışanlar arasında aktif etkileşim olması durumunda, veritabanı hızla büyür ve yöneticilerin bunu sürdürmesi - istatistikleri güncelleme, birleştirme, indeksleme - giderek zorlaşır. Burada farklı stratejiler uygulamamız gerekiyor, bunu nasıl yapacağımızı iyi biliyoruz, tecrübemiz var, paylaşabiliriz.
Bu tür birimlerle yedekleme nasıl uygulanır?
Tam bir DBMS yedeklemesi günde bir kez geceleri, artımlı bir yedekleme ise her saat başı gerçekleştirilir. Ayrıca her gün bir dosya dizini oluşturulur ve bu, dosya deposunun artımlı yedeklemesinin bir parçasıdır.
Tam yedeklemenin tamamlanması ne kadar sürer?
Sabit sürücüye tam yedekleme üç saatte, kısmi yedekleme ise bir saatte tamamlanır. Kasete yazmak daha uzun sürer (ofis dışında saklanan özel bir kasete yedek kopya oluşturan özel bir cihaz; kasete, örneğin sunucu odası yandığında korunacak olan aktarılabilir bir kopya yapılır). Yedekleme, parametreleri daha yüksek olan tamamen aynı sunucuda yapılır - %20 işlemci yüküne sahip bir SQL sunucusu. Yedekleme sırasında elbette sistem çok daha kötü hale gelir, ancak hala işlevseldir.
Tekilleştirme var mı?
Dosyalar var, kendimizde test edeceğiz ve yakında Doküman Yönetiminin yeni sürümüne dahil edilecek. Ayrıca karşı taraf veri tekilleştirme mekanizmasını da test ediyoruz. Gerekli olmadığından, DBMS düzeyinde kayıtların tekilleştirilmesi söz konusu değildir. 1C:Enterprise platformu nesneleri DBMS'de saklar ve bunların tutarlılığından yalnızca platform sorumlu olabilir.
Salt okunur düğümler var mı?
Okuma düğümleri (okumak için herhangi bir veri alması gerekenlere hizmet veren özel sistem düğümleri) yoktur. DO, ayrı bir BI düğümüne yerleştirilecek bir muhasebe sistemi değildir, ancak geliştirme departmanı için mesajların JSON formatında alınıp verildiği ayrı bir düğüm vardır ve tipik çoğaltma süresi birimler ve onlarca saniyedir. Düğüm hala küçük, yaklaşık 800 milyon kaydı var ama hızla büyüyor.
Silinmek üzere işaretlenen e-postalar hiç silinmiyor mu?
Henüz değil. Tabanı hafifletme gibi bir görevimiz yok. 2009 da dahil olmak üzere, silinmek üzere işaretlenmiş mektuplara başvurmanın gerekli olduğu oldukça ciddi birkaç durum vardı. Bu yüzden şimdilik her şeyi saklamaya karar verdik. Ama bunun bedeli haksız hale gelince kaldırmayı düşüneceğiz. Ancak, iz kalmaması için ayrı bir harfi veritabanından tamamen kaldırmanız gerekiyorsa, bu özel istek üzerine yapılabilir.
Neden saklayalım? Eski belgelere erişimle ilgili istatistikleriniz var mı?
İstatistik yok. Daha doğrusu kullanıcı günlüğü formundadır ancak uzun süre saklanmaz. Bir yıldan eski kayıtlar protokolden silinir.
Beş, hatta on yıl önceki eski yazışmaları almanın gerekli olduğu durumlar vardı. Ve bu her zaman boş bir meraktan değil, karmaşık iş kararları vermek için yapılıyordu. Yazışma geçmişi olmasaydı yanlış bir iş kararının verileceği bir durum vardı.
Saklama sürelerine göre belgelerin değeri nasıl belirleniyor ve imha ediliyor?
Kağıt belgeler için bu, herkes gibi olağan geleneksel yöntemle yapılır. Bunu elektronik olanlar için yapmıyoruz; bırakın onlar kendilerine kalsın. Oturma yeri burada. Faydaları var. Herkes iyi.
Hangi gelişme beklentileri var?
Artık DO'muz, bazılarını makalenin başında listelediğimiz yaklaşık 30 dahili sorunu çözüyor. DL aynı zamanda ortaklarımız için yılda iki kez düzenlediğimiz konferansların hazırlanmasında da kullanılıyor: programın tamamı, tüm raporlar, tüm paralel bölümler, salonlar - tüm bunlar DL'ye yazılıyor ve ondan indiriliyor ve basılı bir program yapılmış.
DO'nun halihazırda çözmekte olduğu görevlere ek olarak yolda olan birkaç görevi daha var. Şirket çapında görevler vardır ve yalnızca belirli bir departmanın ihtiyaç duyduğu benzersiz ve nadir görevler vardır. Onlara yardım etmek gerekiyor, bu da sistemi 1C dahilinde kullanmanın "coğrafyasını" genişletmek - uygulama kapsamını genişletmek, tüm bölümlerin sorunlarını çözmek anlamına geliyor. Bu, performans ve güvenilirlik açısından en iyi test olacaktır. Sistemin trilyonlarca kayıt, petabaytlarca bilgi üzerinde çalıştığını görmek isterim.
Kaynak: habr.com