ניהול כאוס: סדר בדברים בעזרת מפה טכנולוגית

תְמוּנָה: Unsplash

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

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

על כאוס ו-DevOps

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

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

איך למצוא איזון בין ייחודיות לפתרונות סדרתיים?

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

אחראי פיתוח: "חבר'ה, אנחנו יכולים איכשהו להעריך מה DevOps עושה עבור מוצרים?"

אנחנו: "אנחנו לא יודעים, לא שאלנו שאלה כזו, אבל באילו אינדיקטורים יש לקחת בחשבון?"

אחראי פיתוח: "מי יודע! לַחשׁוֹב…"

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

אז איך מנתחים תריסר מוצרים עם צוותים גדולים למדי מ-10 עד 200 אנשים וקובעים מדדים מדידים בעת שכפול פתרונות?

1:0 לטובת Chaos, או DevOps על הלהבים

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

משימות ייצור אופייניות

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

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

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

לחיצה על התמונה תפתח אותה בגודל מלא.

העבודה שלנו בחברה מחולקת למספר תחומים פונקציונליים. כיוון התשתית עוסק באופטימיזציה של תפעול כל משאבי ה"ברזל" של המחלקה וכן באוטומציה של פריסת מכונות וירטואליות והסביבה עליהן. כיוון הניטור מספק בקרת ביצועי שירות 24/7; אנו מספקים גם ניטור כשירות למפתחים. כיוון זרימת העבודה מספק לצוותים כלים לניהול תהליכי פיתוח ובדיקה, ניתוח מצב הקוד וקבלת ניתוח על פרויקטים. ולבסוף, הכיוון של webdev מספק פרסום של מהדורות בשרתי העדכונים של GUS ו-FLUS, כמו גם רישוי מוצרים באמצעות שירות LicenseLab. כדי לתמוך בצנרת הייצור, אנו מקימים ומתחזקים שירותי תמיכה רבים ומגוונים למפתחים (תוכלו להאזין לסיפורים על חלקם במפגשים ישנים: Op!DevOps! 2016 и Op!DevOps! 2017). אנו מפתחים גם כלי אוטומציה פנימיים, כולל פתרונות קוד פתוח.

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

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

אתה יכול לקרוא על משימות DevOps טיפוסיות במאמרים האחרים שלנו על Habré: "ניסיון אישי: איך נראית מערכת השילוב הרציף שלנו"ו"אוטומציה של תהליכי פיתוח: איך הטמענו רעיונות DevOps ב-Positive Technologies".

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

דוגמה למידול תהליך CI ייצור

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

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

אם אנחנו מאוד מפשטים ומכלילים את סכימת השחרור שלנו, היא כוללת את השלבים הבאים:

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

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

לחיצה על התמונה תפתח אותה בגודל מלא.

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

הולדת התקווה

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

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

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

1. Нет данных - או לא הולם. יש צורך לנתח את הביקוש לשלב במוצר. או שהניתוח כבר בוצע, אבל בשלב זה אין צורך או אינו מוצדק כלכלית.
2. נִדחֶה - או לא רלוונטי כרגע. דרוש שלב בצנרת, אך אין כוחות לביצוע השנה.
3. מתוכנן. השלב מתוכנן לביצוע השנה.
4. הבין. השלב בצנרת מיושם בנפח הנדרש.

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

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

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

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

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

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

מפה טכנולוגית של תהליך הייצור

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

[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]

אלו הם השלבים של בניית מוצרים [Build], פריסתם לבדיקת שרתים [Deploy], בדיקת [Test], קידום builds לשחרור מאגרים על סמך תוצאות הבדיקה [Promote], הפקה ופרסום רישיונות [License], פרסום [ פרסום] בשרת העדכונים של GUS ומשלוח לשרתי עדכוני FLUS, התקנה ועדכון של רכיבי מוצר על תשתית הלקוח באמצעות Product Configuration Management [Install], וכן איסוף טלמטריה [Telemetry] ממוצרים מותקנים.

בנוסף אליהם, ניתן להבחין בשלבים נפרדים: ניטור מצב תשתית [InfMonitoring], גירסאות קוד מקור [SourceCodeControl], הכנת סביבה [הכנה], ניהול פרויקטים [Workflow], מתן כלי תקשורת לצוותים [תקשורת], הסמכת מוצר [ הסמכה] והבטחת אספקה ​​עצמית של תהליכי CI [CISelfSufficiency] (לדוגמה, עצמאות של מכלולים מהאינטרנט). עשרות שלבים בתהליכים שלנו אפילו לא ייחשבו, כי הם מאוד ספציפיים.

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

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

בתוך החברה שלנו, המפה נוצרת אוטומטית מתבנית ה-jinja כקובץ HTML רגיל, ולאחר מכן מועלית לשרת GitLab Pages. ניתן לצפות בצילום מסך עם דוגמה של מפה שנוצרה במלואה по ссылке.

לחיצה על התמונה תפתח אותה בגודל מלא.

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

מבנה המפה הטכנולוגית שלנו

המפה מורכבת מכמה חלקים:

1. אזור הכותרת - לפניכם תיאור כללי של המפה, מוצגים מושגי יסוד, מוגדרים המשאבים והתוצאות העיקריות של תהליך הייצור.
2. לוח מחוונים - כאן ניתן לשלוט בהצגת הנתונים עבור מוצרים בודדים, ניתן סיכום של השלבים המיושמים והשלבים באופן כללי עבור כל המוצרים.
3. מפה טכנולוגית - תיאור טבלאי של התהליך הטכנולוגי. על המפה:
   • כל השלבים, השלבים והקודים שלהם ניתנים;
   • ניתנים תיאורים קצרים ומלאים של השלבים;
   • מצוינים משאבי הקלט והשירותים המשמשים בכל שלב;
   • התוצאות של כל שלב ושלב בודד מצוינות;
   • מצוין תחום האחריות לכל שלב ושלב;
   • נקבעו המשאבים הטכניים, כגון HDD (SSD), RAM, vCPU ושעות העבודה הנחוצות לתמיכה בעבודה בשלב זה, הן ברגע הנוכחי - עובדה, והן בעתיד - תוכנית;
   • לכל מוצר מצוין אילו שלבים או שלבים טכנולוגיים עבורו יושמו, תוכננו ליישום, לא רלוונטיים או לא יושמו.

קבלת החלטות על בסיס המפה הטכנולוגית

לאחר בחינת המפה, ניתן לבצע מספר פעולות - בהתאם לתפקיד העובד בחברה (מנהל פיתוח, מנהל מוצר, מפתח או בודק):

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

מסכם את כל האמור לעיל

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

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

תוצאות של

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

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

במאמרים הבאים נתאר ביתר פירוט באילו כלים טכניים משתמשים ליישום שלבים טכנולוגיים מסוימים במפה שלנו.

מחברי המאמר:

• אלכסנדר פזדניקוב - ראש אוטומציה (DevOps) בחברת Positive Technologies
• טימור גילמולין - סגן ראש מחלקת אוטומציה (DevOps) בחברת Positive Technologies

מקור: www.habr.com