ISPsystem, סלחו ופרידה! מדוע וכיצד כתבנו את לוח הבקרה של השרת שלנו

שלום! אנחנו "טכנולוגיות אירוח" ולפני 5 שנים השקנו VDSina - אירוח ה-vds הראשון שנוצר במיוחד עבור מפתחים. אנו שואפים לעשות את זה נוח, כמו DigitalOcean, אבל עם תמיכה רוסית, אמצעי תשלום ושרתים ברוסיה. אבל DigitalOcean עוסקת לא רק באמינות ובמחיר, אלא גם בשירות.

התוכנה של ISPsystem התבררה כחבל שקשר את ידינו בדרך לשירות מגניב. לפני שלוש שנים השתמשנו ב-Billmanager billing ובלוח הבקרה של שרת VMmanager ומהר מאוד הבנו שכמעט בלתי אפשרי לספק שירות טוב בלי פאנל משלנו.

איך ISPsystem הרגה את הנוחות

באגים

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

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

איום זמן השבתה

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

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

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

ממשק פאנל לא נוח

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

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

מחזורי חיים קצרים עם עדכוני API תכופים

כתבנו תוספים משלנו - למשל, תוסף עם אמצעי תשלום נוספים שאינם זמינים ב-VMManager.

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

לא ניתן לשנות

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

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

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

והתחלנו בפיתוח.

ארכיטקטורה של הפאנל החדש

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

שלב 1: סוכן שרת

סוכן השרת הוא שרת אינטרנט של Python שמנהל את הספרייה libvirt, שבתורו שולט hypervisor Qemu-kvm.

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

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

הסוכן היה הדבר הראשון שעשינו, מכיוון שהוא לא דרש שום ממשק וניתן היה לבדוק אותו ישירות ממסוף השרת.

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

שלב 2. חיוב

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

אנחנו קוראים לחיוב "לוח בקרה": הוא מכיל לא רק כסף ושירותים, אלא גם ניהול, תמיכת לקוחות ועוד הרבה יותר.

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

החיוב החדש השתמש בשתי ערימות: PHP קלאסית, MySQL (ובעתיד מתוכנן לעבור ל-PostgreSQL), Yii2 כמסגרת ב-backend ו-VueJS בחזית. הערימות פועלות ללא תלות זו בזו, מפותחות על ידי אנשים שונים ומתקשרות באמצעות ה-API של JSON. לפיתוח אז והיום אנו משתמשים PHPStorm и סופת הרשת מ-JetBrains ואוהב אותם מאוד (היי חברים!)

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

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

שלב 3. ממשק

הממשק הוא פרי מוחו של הצוות שלנו.

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

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

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

חזיתי

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

חיבור בין Frontend ו-backend

ה-frontend היה מחובר ל-backend באמצעות הודעות דחיפה. הייתי צריך לעבוד קשה ולכתוב את המטפל שלי, אבל עכשיו המידע בדף מתעדכן כמעט באופן מיידי.

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

שלב 4. ערכת בדיקות והגירה

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

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

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

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

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

לסיכום: זה חי!

סוף טוב

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

סקירה ראשונה לאחר השקת הפאנל החדש

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

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

מה הלאה?

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

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

במאמר הבא נספר לכם כיצד השקנו את תעריף Hi-CPU: על חומרה, תוכנה, אילו בעיות פתרנו ומה השגנו.

מקור: www.habr.com