אנחנו בודקים את עצמנו: איך 1C נפרסת ואיך היא מנוהלת: זרימת מסמכים בתוך חברת 1C

ב-1C, אנו משתמשים באופן נרחב בפיתוחים שלנו כדי לארגן את עבודת החברה. באופן מיוחד, "1C: זרימת מסמכים 8". בנוסף לניהול מסמכים (כפי שהשם מרמז), הוא גם מודרני ECM-system (Enterprise Content Management - ניהול תוכן ארגוני) עם מגוון רחב של פונקציונליות - דואר, יומני עבודה של עובדים, ארגון גישה משותפת למשאבים (למשל, הזמנת חדרי ישיבות), מעקב אחר זמן, פורום ארגוני ועוד.

יותר מאלף עובדים משתמשים בניהול מסמכים ב-1C. בסיס הנתונים כבר הפך למרשים (11 מיליארד רשומות), מה שאומר שהוא דורש טיפול זהיר יותר וציוד חזק יותר.

איך המערכת שלנו עובדת, באילו קשיים אנו נתקלים בעת תחזוקת מסד הנתונים וכיצד אנו פותרים אותם (אנו משתמשים ב-MS SQL Server כ-DBMS) – נספר לכם במאמר.

למי שקורא לראשונה על מוצרי 1C.
1C:Document Flow הוא פתרון אפליקציה (קונפיגורציה) המיושם על בסיס מסגרת לפיתוח אפליקציות עסקיות - פלטפורמת 1C:Enterprise.

"1C: Document Flow 8" (בקיצור DO) מאפשר לך להפוך את העבודה עם מסמכים לאוטומטיים בארגון. אחד הכלים העיקריים לאינטראקציה עם העובדים הוא אימייל. בנוסף לדואר, DO פותר גם בעיות אחרות:

• מעקב אחר זמן
• מעקב אחר היעדרות עובדים
• בקשות לשליחים/הובלה
• לוחות שנה לעבודה של עובדים
• רישום התכתבות
• אנשי קשר לעובדים (פנקס כתובות)
• פורום תאגידי
• הזמנת חדרים
• תכנון אירוע
• CRM
• עבודה קולקטיבית עם קבצים (עם שמירת גרסאות קבצים)
• וכו '

אנחנו נכנסים לניהול מסמכים לקוח רזה (יישום מקורי להפעלה) מ-Windows, Linux, macOS, לקוח אינטרנט (מדפדפנים) ו לקוח נייד - תלוי במצב.

ובזכות המוצר הנוסף שלנו המחובר ל-Document Flow - מערכת אינטראקציה – אנחנו ישירות ב-Document Flow מקבלים את הפונקציונליות של המסנג'ר – צ'אטים, שיחות שמע ווידאו (כולל שיחות קבוצתיות, שעכשיו הפכו חשובות במיוחד, כולל מלקוח נייד), החלפת קבצים מהירה בתוספת יכולת כתיבת צ'אט בוטים שמפשטים עבודה עם המערכת. יתרון נוסף בשימוש במערכת האינטראקציה (לעומת שליחים אחרים) הוא היכולת לנהל דיונים הקשריים הקשורים לאובייקטים ספציפיים של Document Flow - מסמכים, אירועים וכו'. כלומר, מערכת האינטראקציה משולבת באופן עמוק עם אפליקציית היעד, ואינה פועלת כ"כפתור נפרד" בלבד.

מספר המכתבים ב-DO שלנו כבר עלה על 100 מיליון, ובאופן כללי יש יותר מ-11 מיליארד רשומות ב-DBMS. בסך הכל, המערכת משתמשת בכמעט 30 TB של אחסון: נפח מסד הנתונים הוא 7,5 TB, קבצים לעבודה קולקטיבית מאוחסנים בנפרד ותופסים עוד 21 TB.

אם אנחנו מדברים על מספרים ספציפיים יותר, הנה מספר האותיות והקבצים כרגע:

• מיילים יוצאים – 14,7 מיליון.
• מכתבים נכנסים – 85,4 מיליון.
• גרסאות קובץ – 70,8 מיליון.
• מסמכים פנימיים – 30,6 אלף.

ל-DO יש יותר מסתם דואר וקבצים. להלן הנתונים עבור אובייקטים חשבונאיים אחרים:

• הזמנת חדרי ישיבות – 52
• דוחות שבועיים – 153
• דוחות יומיים – 628
• אשרות אישור – 11
• מסמכים נכנסים – 79
• מסמכים יוצאים – 28
• ערכים על אירועים ביומני עבודה של משתמשים – 168
• פניות לשליחים – 21
• צדדים שכנגד – 81
• רישומי עבודה מול צדדים נגדיים – 45
• אנשי קשר של צדדים שכנגד – 41
• אירועים – 10
• פרויקטים – 6
• משימות עובדים – 245
• הודעות בפורום – 26
• הודעות צ'אט – 891 095
• תהליכים עסקיים - 109 אינטראקציה בין עובדים מתרחשת באמצעות תהליכים - אישור, ביצוע, סקירה, רישום, חתימה וכו'. אנו מודדים את משך התהליכים, מספר המחזורים, מספר המשתתפים, מספר ההחזרות, מספר הבקשות לשינוי מועדים. ומידע זה שימושי מאוד לניתוח על מנת להבין אילו תהליכים מתרחשים בארגון ולהגביר את היעילות של שיתוף הפעולה בין העובדים.

על איזה ציוד אנחנו מעבדים את כל זה?

נתונים אלו מצביעים על היקף משימות מרשים, ולכן עמדנו בפני הצורך להקצות ציוד פרודוקטיבי למדי לצרכי החברות הבנות הפנימיות. נכון לעכשיו, המאפיינים שלו הם כדלקמן: 38 ליבות, 240 GB של זיכרון RAM, 26 TB של דיסקים. להלן טבלת שרתים:


בעתיד, אנו מתכננים להגדיל את הקיבולת של הציוד.

איך העניינים מסתדרים עם עומס השרת?

פעילות הרשת מעולם לא הייתה בעיה עבורנו או עבור הלקוחות שלנו. ככלל, נקודת התורפה היא המעבד והדיסקים, כי כולם כבר יודעים להתמודד עם חוסר זיכרון. הנה צילומי מסך של השרתים שלנו מ-Resource Monitor, שמראים שאין לנו עומס נוראי, זה מאוד צנוע.

לדוגמה, בצילום המסך למטה אנו רואים שרת SQL שבו עומס המעבד הוא 23%. וזה אינדיקטור טוב מאוד (לשם השוואה: אם העומס מתקרב ל-70%, סביר להניח שהעובדים יראו האטות משמעותיות בעבודה).

צילום המסך השני מציג את שרת האפליקציות עליו פועלת פלטפורמת 1C:Enterprise - הוא משרת רק הפעלות של משתמשים. כאן עומס המעבד מעט גבוה יותר - 38%, הוא חלק ורגוע. יש טעינת דיסק, אבל זה מקובל.

צילום המסך השלישי מציג שרת 1C:Enterprise אחר (זהו השני, יש לנו שניים מהם באשכול). רק הקודם משרת משתמשים, ורובוטים עובדים על זה. למשל, הם מקבלים דואר, מנתבים מסמכים, מחליפים נתונים, מחשבים זכויות וכו'. כל פעילויות הרקע הללו מבצעות כ-90-100 עבודות רקע. והשרת הזה עמוס מאוד - 88%. אבל זה לא משפיע על אנשים, והוא מיישם בדיוק את כל האוטומציה שניהול מסמכים צריך לעשות.

מהם המדדים למדידת ביצועים?

יש לנו תת-מערכת רצינית מובנית בחברות הבנות שלנו למדידת מדדי ביצועים וחישוב מדדים שונים. זה הכרחי כדי להבין גם ברגע הנוכחי בזמן וגם מנקודת מבט היסטורית מה קורה במערכת, מה מחמיר, מה משתפר. כלי ניטור - מדדים ומדידות זמן - כלולים במשלוח הסטנדרטי של "1C: Document Flow 8". המדדים דורשים התאמה אישית במהלך ההטמעה, אך המנגנון עצמו הוא סטנדרטי.

מדדים הם מדידות של אינדיקטורים עסקיים שונים בנקודות זמן מסוימות (לדוגמה, זמן משלוח הדואר הממוצע הוא 10 דקות).

אחד המדדים מציג את מספר המשתמשים הפעילים במסד הנתונים. בממוצע יש 1000-1400 מהם במהלך היום. הגרף מראה שבזמן צילום המסך היו 2144 משתמשים פעילים במסד הנתונים.

יש יותר מ-30 פעולות כאלה, הרשימה תחת חתך.רשימה

• כניסה
• התנתק
• טוען דואר
• שינוי תוקפו של אובייקט
• שינוי זכויות גישה
• שינוי נושא של תהליך
• שינוי קבוצת עבודה של אובייקט
• שינוי הרכב הערכה
• שינוי קובץ
• ייבוא ​​קבצים
• שליחה בדואר
• העברת קבצים
• ניתוב מחדש של משימה
• חתימה על החתימה האלקטרונית
• חפש לפי פרטים
• חיפוש טקסט מלא
• קבלת קובץ
• הפסקת תהליך
• סקירה
• פענוח
• רישום מסמכים
• סרוק
• ביטול סימון המחיקה
• יצירת אובייקט
• שומר בדיסק
• תחילת התהליך
• מחיקת ערכי יומן משתמש
• הסרת חתימה אלקטרונית
• הגדרת סימן מחיקה
• הצפנה
• ייצא תיקיה

בשבוע שלפני האחרון, פעילות המשתמשים הממוצעת שלנו עלתה פי אחד וחצי (מוצג באדום בגרף) – זאת בשל המעבר של רוב העובדים לעבודה מרחוק (עקב אירועים ידועים). כמו כן, מספר המשתמשים הפעילים גדל פי 3 (מוצג בכחול בצילום המסך), כאשר העובדים החלו להשתמש באופן פעיל בטלפונים ניידים: כל לקוח נייד יוצר חיבור לשרת. כעת, בממוצע, לכל אחד מהעובדים שלנו יש 2 חיבורים לשרת.

עבורנו, כמנהלים, זהו אות לכך שעלינו להיות קשובים יותר לבעיות ביצועים ולראות אם המצב החמיר. אבל אנחנו מסתכלים על זה על סמך פרמטרים אחרים. לדוגמה, כיצד משתנה זמן מסירת הדואר עבור ניתוב פנימי (מוצג בכחול בצילום המסך למטה). אנחנו רואים שזה היה תנודתי עד השנה, אבל עכשיו זה יציב - מבחינתנו זה אינדיקטור שהכל בסדר עם המערכת.

מדד יישומי נוסף עבורנו הוא זמן ההמתנה הממוצע להורדת מכתבים משרת הדואר (מוצג באדום בצילום המסך). בגדול, כמה זמן המכתב ירחף באינטרנט לפני שהוא יגיע לעובד שלנו. צילום המסך מראה שגם הזמן הזה לא השתנה בשום צורה לאחרונה. יש קוצים מבודדים - אבל הם לא קשורים לעיכובים, אלא לעובדה שהזמן בשרתי הדואר אובד.

או, למשל, מדד אחר (מוצג בכחול בצילום המסך) – עדכון אותיות בתיקייה. פתיחת תיקיית דואר היא פעולה נפוצה מאוד וצריכה להיעשות במהירות. אנו מודדים כמה מהר הוא מתבצע. אינדיקטור זה נמדד עבור כל לקוח. ניתן לראות גם את התמונה הכוללת של החברה וגם את הדינמיקה, למשל, עבור עובד בודד. צילום המסך מראה שעד השנה המדד לא היה מאוזן, אז עשינו מספר שיפורים, ועכשיו זה לא מחמיר - הגרף כמעט שטוח.

מדדים הם בעצם כלי של מנהל מערכת לניטור המערכת, לתגובה מהירה לכל שינוי בהתנהגות המערכת. צילום המסך מציג מדדי חברות בת פנימיות לשנה. הקפיצה בגרפים נובעת מכך שקיבלנו משימות לפתח חברות בת פנימיות.

הנה רשימה של עוד כמה מדדים (תחת החתך).
מדדים

• פעילות המשתמש
• משתמשים פעילים
• תהליכים פעילים
• מספר קבצים
• גודל קובץ (MB)
• מספר מסמכים
• מספר החפצים שיש לשלוח לנמענים
• מספר צדדים נגדיים
• משימות לא גמורות
• זמן המתנה ממוצע להורדת מיילים משרת הדואר במהלך 10 הדקות האחרונות
• מאגר נתונים חיצוני: מספר קבצים
• גבול מפגר מהתאריך הנוכחי
• תור ארוך
• תור תפעולי
• גיל חשבון גולמי לפי ניתוב חיצוני
• גודל תור קבלת ניתוב פנימי (תור ארוך)
• גודל תור קבלת ניתוב פנימי (תור מהיר)
• זמן משלוח דואר באמצעות ניתוב פנימי (תור ארוך)
• זמן משלוח דואר באמצעות ניתוב פנימי (תור מהיר)
• זמן משלוח דואר באמצעות ניתוב חיצוני (ממוצע)
• מספר מסמכים הזמנה
• מספר מסמכים היעדרות
• מספר מסמכים "תיעוד עבודה עם צד שכנגד"
• דואר עדכון מכתבים בתיקייה
• דואר פתיחת כרטיס מכתב
• דואר העברת מכתב לתיקיה
• דואר נווט בין תיקיות

המערכת שלנו מודדת יותר מ-150 אינדיקטורים מסביב לשעון, אך לא ניתן לנטר במהירות את כולם. הם עשויים להיות שימושיים מאוחר יותר, בפרספקטיבה היסטורית כלשהי, ותוכל להתמקד באלה החשובים ביותר עבור העסק.

באחד המיישומים, למשל, נבחרו רק 5 אינדיקטורים. הלקוח שם לו למטרה ליצור סט מינימלי של אינדיקטורים, אך יחד עם זאת כזה שיכסה את תרחישי העבודה העיקריים. לא יהיה זה מוצדק לכלול 150 מדדים בתעודת הקבלה, כי גם בתוך המיזם קשה להסכים אילו מדדים נחשבים מקובלים. והם ידעו על 5 האינדיקטורים הללו וכבר הציגו אותם למערכת לפני תחילת פרויקט היישום, כולל אותם בתיעוד התחרות: זמן פתיחת כרטיס לא יותר מ-3 שניות, זמן להשלמת משימה עם קובץ מס. יותר מ-5 שניות וכו'. בחברות הבנות שלנו היו לנו מדדים ששיקפו בצורה ברורה מאוד את הבקשה המקורית מהמפרט הטכני של הלקוח.

יש לנו גם ניתוח פרופיל של מדידות ביצועים. מדדי ביצועים הם רישום של משך כל פעולה שוטפת (כתיבת מכתב למאגר, שליחת מכתב לשרת דואר וכו'). זה משמש אך ורק על ידי טכנאים. אנו צוברים הרבה מדדי ביצועים בתוכנית שלנו. אנו מודדים כיום כ-1500 פעולות מפתח, המחולקות לפרופילים.

אחד הפרופילים החשובים ביותר עבורנו הוא "רשימת האינדיקטורים העיקריים של דואר מנקודת מבט צרכנית". פרופיל זה כולל, למשל, את האינדיקטורים הבאים:

• ביצוע הפקודה: בחר לפי תג
• פתיחת טופס: טופס רשימה
• ביצוע הפקודה: בחר לפי תיקיה
• הצגת אות באזור הקריאה
• שמירת מכתב בתיקייה המועדפת עליך
• חפש אותיות לפי פרטים
• יצירת מכתב

אם אנו רואים שהמדד עבור אינדיקטור עסקי כלשהו הפך להיות גדול מדי (לדוגמה, מכתבים ממשתמש מסוים החלו להגיע במשך זמן רב מאוד), אנו מתחילים להבין אותו ולפנות למדידת זמן הפעולות הטכניות. יש לנו פעולה טכנית "ארכיון מכתבים בשרת דואר" - אנו רואים שחרג מהזמן לפעולה זו בתקופה האחרונה. פעולה זו, בתורה, מפורקת לפעולות אחרות - למשל, יצירת חיבור עם שרת דואר. אנחנו רואים שמשום מה הוא פתאום הפך לגדול מאוד (יש לנו את כל המדידות לחודש - אפשר להשוות שבשבוע שעבר זה היה 10 מילישניות, ועכשיו זה 1000 מילישניות). ואנחנו מבינים שמשהו פה מקולקל - צריך לתקן אותו.

איך נשמור על בסיס נתונים כל כך גדול?

ה-DO הפנימי שלנו הוא דוגמה לפרויקט שעובד באמת בעומס גבוה. בואו נדבר על התכונות הטכניות של מסד הנתונים שלו.

כמה זמן לוקח לבנות מחדש טבלאות מסד נתונים גדולות?

שרת SQL דורש תחזוקה תקופתית, מסדר את הטבלאות. בצורה טובה, זה צריך להיעשות לפחות פעם ביום, ואפילו לעתים קרובות יותר עבור שולחנות ביקוש גבוה. אבל אם מסד הנתונים גדול (ומספר הרשומות שלנו כבר עלה על 11 מיליארד), אז הטיפול בו לא קל.

עשינו ארגון מחדש של השולחן לפני 6 שנים, אבל אז זה התחיל לקחת כל כך הרבה זמן שלא השתלבנו יותר במרווחי הלילה. ומכיוון שפעולות אלו עומסות בכבדות את שרת SQL, הוא אינו יכול לשרת ביעילות משתמשים אחרים.

לכן, כעת עלינו להשתמש בטריקים שונים. לדוגמה, איננו יכולים לבצע הליכים אלה על מערכי נתונים שלמים. אתה צריך לפנות לנוהל Update Sample 500000 rows - זה לוקח 14 דקות. היא לא מעדכנת סטטיסטיקה על כל הנתונים בטבלה, אלא בוחרת חצי מיליון שורות ומשתמשת בהן כדי לחשב סטטיסטיקה שהיא משתמשת בה עבור כל הטבלה. זו איזושהי הנחה, אבל אנחנו נאלצים לעשות את זה, כי עבור טבלה ספציפית, איסוף סטטיסטיקות על כל מיליארד הרשומות ייקח זמן לא מקובל.

ביצענו אופטימיזציה של פעולות תחזוקה אחרות על ידי הפיכתן לחלקיות.

תחזוקת DBMS היא בדרך כלל משימה מורכבת. במקרה של אינטראקציה פעילה בין עובדים, בסיס הנתונים גדל במהירות, ולמנהלים קשה יותר ויותר לתחזק אותו - עדכון סטטיסטיקות, איחוי, אינדקס. כאן אנחנו צריכים ליישם אסטרטגיות שונות, אנחנו יודעים היטב איך לעשות את זה, יש לנו ניסיון, אנחנו יכולים לחלוק אותו.

כיצד מיושם גיבוי עם נפחים כאלה?

גיבוי DBMS מלא מתבצע פעם ביום בלילה, גיבוי מצטבר - כל שעה. כמו כן, ספריית קבצים נוצרת מדי יום, והיא חלק מהגיבוי המצטבר של אחסון הקבצים.

כמה זמן לוקח להשלים גיבוי מלא?

גיבוי מלא לכונן קשיח מסתיים תוך שלוש שעות, גיבוי חלקי תוך שעה. לוקח יותר זמן לכתוב לטייפ (מכשיר מיוחד שמייצר עותק גיבוי לקלטת מיוחדת המאוחסנת מחוץ למשרד; עותק ניתן להעברה לקלטת, שיישמר אם, למשל, חדר השרת נשרף). הגיבוי נעשה בדיוק על אותו שרת, שהפרמטרים שלו היו גבוהים יותר - שרת SQL עם 20% עומס מעבד. בזמן הגיבוי, כמובן, המערכת הופכת להרבה יותר גרועה, אבל היא עדיין מתפקדת.

האם יש מניעת כפילות?

מניעת כפילות יש קבצים, נבדוק את זה על עצמנו, ובקרוב זה ייכלל בגרסה החדשה של ניהול מסמכים. אנחנו גם בודקים את מנגנון מניעת הכפילויות של הצד שכנגד. אין מניעת כפילויות של רשומות ברמת DBMS, מכיוון שאין צורך בכך. פלטפורמת 1C:Enterprise מאחסנת אובייקטים ב-DBMS, ורק הפלטפורמה יכולה להיות אחראית לעקביות שלהם.

האם יש צמתים לקריאה בלבד?

אין צמתי קריאה (צמתי מערכת ייעודיים המשרתים את מי שצריך לקבל נתונים כלשהם לקריאה). DO היא לא מערכת הנהלת חשבונות לשים על צומת BI נפרד, אלא יש צומת נפרד למחלקת הפיתוח, איתו מחליפים הודעות בפורמט JSON, וזמן השכפול האופייני הוא יחידות ועשרות שניות. הצומת עדיין קטן, יש לו כ-800 מיליון רשומות, אבל הוא גדל במהירות.

האם אימיילים שסומנו למחיקה אינם נמחקים כלל?

עדיין לא. אין לנו את המשימה להפוך את הבסיס לקל יותר. היו כמה מקרים די חמורים שבהם היה צורך להתייחס למכתבים שסומנו למחיקה, כולל 2009. לכן החלטנו לשמור הכל לעת עתה. אבל כשהעלות של זה תהיה בלתי מוצדקת, נחשוב על הסרה. אבל, אם אתה צריך להסיר מכתב נפרד ממסד הנתונים לחלוטין כדי שלא יהיו עקבות, אז זה יכול להיעשות על ידי בקשה מיוחדת.

למה לאחסן אותו? האם יש לך נתונים סטטיסטיים על גישה למסמכים ישנים?

אין סטטיסטיקה. ליתר דיוק, זה בצורה של יומן משתמש, אבל זה לא נשמר לאורך זמן. ערכים מעל שנה נמחקים מהפרוטוקול.

היו מצבים שבהם היה צורך לאחזר תכתובות ישנות מלפני חמש או אפילו עשר שנים. וזה תמיד נעשה לא מתוך סקרנות סרק, אלא כדי לקבל החלטות עסקיות מורכבות. היה מקרה שבו, ללא היסטוריית התכתבויות, הייתה מתקבלת החלטה עסקית שגויה.

כיצד מעריכים ומשמידים את שווי המסמכים לפי תקופות אחסון?

עבור מסמכי נייר זה נעשה בדרך המסורתית הרגילה, כמו כולם. אנחנו לא עושים את זה עבור אלקטרוניים - תנו להם לשמור אותם לעצמם. הישיבה כאן. יש יתרונות. כולם בסדר.

אילו סיכויי פיתוח יש?

כעת ה-DO שלנו פותר כ-30 בעיות פנימיות, את חלקן פירטנו בתחילת המאמר. ה-DL משמש גם להכנת כנסים שאנו עורכים פעמיים בשנה עבור השותפים שלנו: כל התכנית, כל הדוחות, כל המדורים המקבילים, אולמות - כל זה מוקלד ב-DL, ואז מורידים ממנו, ותכנית מודפסת עשוי.

יש עוד כמה משימות בדרך ל-DO, בנוסף לאלו שהוא כבר פותר. ישנן משימות כלל-חברה, וישנן ייחודיות ונדירות, הנחוצות רק למחלקה ספציפית. יש צורך לעזור להם, כלומר הרחבת ה"גיאוגרפיה" של השימוש במערכת בתוך 1C - הרחבת היקף היישום, פתרון הבעיות של כל המחלקות. זה יהיה המבחן הטוב ביותר לביצועים ואמינות. הייתי רוצה לראות את המערכת עובדת על טריליוני רשומות, פטה-בייט של מידע.

מקור: www.habr.com