Platform Engineering 101: מעבר למערכות טיקטים מסורתיות ב-Azure

By Mirko Peters · 2026-08-13

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

Automatically translated with AI from the original post. Read the English original

Titelbild: Platform Engineering 101: Moving Beyond Traditional Ticketing Systems in Azure

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

מבוא: צוואר הבקבוק של טיקטים מסורתיים ב-Azure

בואו נצייר תמונה מוכרת. הארגון שלכם העביר את עומסי העבודה שלו ל-Microsoft Azure. אימצתם את הענן, אתם משתמשים ב-Azure Kubernetes Service (AKS), ב-Azure SQL, ב-Cosmos DB וב-App Services. על הנייר, אתם מודרניים. אבל אם תסתכלו מקרוב על תהליך העבודה שלכם, תגלו שהמפתחים מתייחסים ל-Azure בדיוק כפי שהתייחסו פעם לחדר השרתים המקומי: דרך חומה של ביורוקרטיה ותורי טיקטים.

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

מהו Platform Engineering ומדוע הוא חשוב?

אז איך מתקנים את זה? נכנס ל-Platform Engineering. בשנים האחרונות Platform Engineering הפך להתפתחות המובהקת של DevOps. בעוד ש-DevOps הרס בתיאוריה את החומה בין פיתוח לתפעול, בפועל ארגונים רבים פשוט העבירו את כל נטל התפעול אל המפתחים. לפתע נדרש מהמפתחים להיות מומחים ב-Kubernetes, ב-Terraform, באבטחת רשתות ובמדיניות IAM של Azure, וכל זאת תוך כדי כתיבת לוגיקה עסקית.

Platform Engineering מכיר בכך שמצב זה אינו בר-קיימא. במקום לאלץ את המפתחים להפוך למומחי תשתית או להמתין בתור טיקטים, Platform Engineering מתייחס לחוויית המפתח כאל מוצר. צוות פלטפורמה ייעודי בונה Internal Developer Platform (IDP) שמסתיר את המורכבות הבסיסית של Azure.

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

מעבר לתפעול ידני: החזון של Internal Developer Platforms

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

הבעיה עם סקריפטים אד-הוק והקצאה לא מבוקרת (Wild West)

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

נקודת המתיקות של IDP

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

עמודי התווך של בניית פלטפורמת מפתחים מבוססת Azure

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

1. תשתית כקוד (IaC) וקטלוגי מודולים

בלב כל פלטפורמת ענן נמצאת תשתית כקוד. באקוסיסטם של Azure, המשמעות היא בדרך כלל Terraform, Bicep או תבניות Azure Resource Manager (ARM). עם זאת, כתיבת קבצי Bicep בלבד אינה מספיקה. צוות הפלטפורמה צריך לבנות קטלוג אוצר של תבניות מודולריות, לשימוש חוזר ומאובטחות. לדוגמה, במקום לתת למפתח לכתוב בעצמו את תצורת מסד הנתונים מאפס, הפלטפורמה מספקת מודול Azure SQL שכבר כולל הצפנה ברמת ארגון, שילוב רשתי מתאים ומדיניות גיבוי מוגדרת מראש. המפתח רק מזין את שם היישום ואת הרמה.

2. מדיניות כקוד עם Azure Policy

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

3. אינטגרציה חלקה של CI/CD ו-GitOps

ה-IDP שלכם לא אמור לפעול בחלל ריק. הוא חייב להשתלב באופן מובנה בבקרת הגרסאות ובצינורות הפריסה שלכם. בין אם אתם משתמשים ב-GitHub Actions, ב-Azure DevOps או ב-ArgoCD ל-GitOps, הפלטפורמה צריכה לתזמר את הצינור מרגע ה-commit של הקוד ועד הפריסה ב-Azure, בצורה חלקה. מפתחים צריכים להיות מסוגלים להפעיל סביבות שייווצרו או יפורקו ישירות מתוך ה-pull requests שלהם.

4. ניטור ותצפיתיות מאוחדת

אי אפשר לנהל מה שאי אפשר למדוד. פלטפורמה טובה מספקת תצפיתיות מיידית על ידי חיבור היישומים ישירות ל-Azure Monitor, ל-Application Insights ול-Azure Log Analytics. כשמפתח מקים microservice חדש דרך הפלטפורמה, הרישום, המדדים והמעקב מוגדרים ומחוברים אוטומטית, בלי צורך בהטמעה ידנית.

האצת לוחות זמנים לאספקה וצמצום חיכוך למפתחים

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

זמן עד השוק ותדירות פריסה

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

מניעת שחיקה של מפתחים

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

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

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

לנהל את הפלטפורמה כמוצר

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

התחילו בקטן עם פלטפורמה מינימלית בת-קיימא (MVP)

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

התמקדו רבות בתיעוד למפתחים ובחוויית הפורטל

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

סיכום: העצמת צוותי פיתוח מודרניים לעתיד

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

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