סיפורי מפתחים של 1C: של אדמין

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

ערוץ תקשורת מהיר

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

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

כל זה הוגדר בהצלחה, הופעל ובדרך כלל עבד ללא תקלות.

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

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

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

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

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

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

בהמשך, כל הבקשות שלנו למחלקת ה-IT נפתרו מהר מאוד ולא התעוררו עוד חילוקי דעות.

פנה למנהל המערכת שלך

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

- נסה שוב באמצעות הוראות אלה. הכל מתואר שם בפירוט רב. אם זה לא עובד, כתוב למחבר האתר הזה, אולי הוא יכול לעזור.
"לא," אני אומר, "זה לא יעזור."
- Почему?
- אני המחבר של האתר הזה... (

כתוצאה מכך, השקנו אותו ב- Apache ללא בעיות. IIS מעולם לא הובס.

רמה אחת יותר עמוקה

היה לנו לקוח - מפעל ייצור קטן. היה להם שרת, מעין 3 ב-1 "קלאסי": שרת מסוף + שרת יישומים + שרת מסד נתונים. הם עבדו בתצורה ספציפית לתעשייה המבוססת על UPP, היו בערך 15-20 משתמשים, והביצועים של המערכת, באופן עקרוני, התאימו לכולם.

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

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

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

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

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

הממ... שרת וירטואלי? נראה שמעולם לא הייתה שום וירטואליזציה ומעולם לא הייתה... אני זוכר בעיה די מוכרת עם חוסר האפשרות להעביר מפתח שרת 1C למכונה וירטואלית ב-Hyper-V ב-Windows Server 2008. וכאן מתחילים להיווצר בי כמה חשדות...

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

אז מה? הוראות הרשויות והמלצותיי בוצעו, התפקידים הופרדו. ניתן לסגור את המשימה.

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

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

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

לוח זמנים לחופשות בכונן הקשיח

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

קודם כל, יש צורך לפרוס מסדי נתונים של ייצור ובדיקה. המפתח קיבל את נתוני החיבור, נכנס לשרת, רואה MS SQL מותקן, שרת 1C, רואה 2 כוננים לוגיים: כונן "C" בקיבולת 250 גיגה-בייט וכונן "D" בקיבולת 1 טרה-בייט. ובכן, "C" היא המערכת, "D" היא עבור נתונים, המפתח מחליט באופן הגיוני ופורס את כל מסדי הנתונים שם. אפילו הקמתי תוכניות תחזוקה, כולל גיבוי, לכל מקרה (למרות שאיננו אחראים לכך). נכון, גיבויים נוספו כאן ל-"D". בעתיד, תוכנן להגדיר אותו מחדש למשאב רשת נפרד כלשהו.

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

הכל התנהל כשורה עד בבוקר יום שני אחד שבו התגלה שדיסק מסד הנתונים חסר. פשוט אין "D" בשרת וזהו.

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

תודה לאל, הוא לא הצליח למחוק את קבצי מסד הנתונים והצליח לשחזר את מסד הנתונים היצרני.

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

אבל זה סיפור אחר לגמרי...

מקור: www.habr.com