קודם כל: למסגר מחדש את השיחה
הטעות הכי גדולה שמהנדסים עושים כשהם מציעים כלי שיחליף את העבודה שלהם היא למסגר את זה כ-"מה שבניתי לא מספיק טוב." זה סיכון קריירה. אף אחד לא רוצה לשמוע שצריך לזרוק את העבודה שלו.
המסגור הנכון הוא: "מה שבניתי פתר את הבעיה שהיתה לנו לפני 18 חודשים. הבעיה גדלה. הפתרון צריך לגדול איתה."
זה לא ספין. זה מדויק. כשכתבתם את הסקריפט, היו לכם 8 firewalls מ-2 ספקים. עכשיו יש לכם 35 firewalls מ-4 ספקים. הסקריפט היה הקריאה הנכונה אז. הוא הקריאה הלא נכונה עכשיו. השיקול ההנדסי שלכם היה נכון אז והוא נכון גם עכשיו - מה שהשתנה הוא הסקייל של הבעיה.
הפלייבוק ב-4 צעדים
עקבו אחרי הזמן שלכם במשך שבועיים. בלי רחמים.
לפני שמדברים עם מישהו, אתם צריכים דאטה. עקבו אחרי כל שעה שאתם מבלים על עבודה הקשורה לסקריפטים במשך שבועיים. כללו הכל: תחזוקה, דיבאגינג, on-call, עדכוני API של ספקים, הגיליון של יום שני, התאוששות מתקלות, עדכוני תיעוד. רשמו את זה. אל תעריכו מזיכרון - הזיכרון נחמד אליכם והמנהל לא יסמוך עליו.
המטרה היא מספר יחיד: שעות בשבוע שמוקדשות לתחזוקת אוטומציית תשתיות. מהניסיון שלנו, המספר הזה בדרך כלל נע בין 10-15 שעות למתחזק הראשי. זה 25-40% מהקיבולת של מהנדס בכיר.
הציגו את הבעיה כסיכון עסקי, לא כתלונה אישית.
למנהל שלכם לא אכפת שנמאס לכם לתחזק סקריפטים. זה נשמע כמו בעיית מורל, לא בעיה עסקית. אבל למנהל שלכם כן אכפת מ:
- סיכון אדם-מפתח. "אם אני יוצא למילואים ל-30 יום, אף אחד לא יכול לתחזק או לדבג את מערכת הסנכרון."
- חשיפה ל-split-brain. "כשהסקריפט נכשל באמצע push, יש לנו firewalls עם פוליסיות שונות. זה ממצא compliance שמחכה לקרות."
- עלות הזדמנות. "אני מבלה 12 שעות בשבוע על קוד דבק במקום על פרויקט ה-micro-segmentation שאנחנו כל הזמן דוחים."
- תקרת סקייל. "אנחנו מוסיפים עוד 2 אתרים ברבעון הבא. הסקריפט לא יתמודד עם זה בלי שכתוב מאסיבי."
אלה טיעוני סיכון ויעילות. זו שפת מנהלים. זה עובד כי זה מתאר בעיות ארגוניות, לא בעיות שלכם.
בקשו בדיקה, לא רכישה.
אל תבקשו מהמנהל לקנות משהו. אל תציגו דף תמחור של ספק. אל תשלחו מצגת מכירות. בקשו אישור לבדוק חלופה אחת למשך 3 שעות. זהו. שלוש שעות. בלי תקציב. בלי התחייבות. בלי תהליך רכש.
Cyberm8 מותקן כ-container. אפשר למשוך אותו על host בדיקה, לחבר אותו ל-firewall אחד, ולהריץ סנכרון תוך פחות משעה. אם זה עובד, יש לכם דמו להראות למנהל. אם לא, הפסדתם אחר צהריים. הסיכון אסימטרי לטובתכם.
תראו, אל תספרו. השתמשו בתרחיש הכי גרוע שלהם.
אחרי הבדיקה, קבעו 15 דקות עם המנהל. תראו לו שני דברים:
- ה-happy path. חוק שנדחף לשני ספקי firewall במקביל, עם audit trail אחיד. הדגישו: "בלי Python. בלי קוד ספציפי לספק. בלי ניהול sessions."
- ה-failure path. סמלצו API timeout באמצע push. הראו את ה-rollback האוטומטי. הדגישו: "זה התרחיש שמעיר אותי בשתיים בלילה. הפלטפורמה מטפלת בזה. אני ישן."
הדמו של הכישלון חזק יותר מהדמו של ההצלחה. כל מנהל חווה אסקלציה בשתיים בלילה. להראות לו שזה נעלם שווה יותר מכל מצגת.
התסריט לשיחה
הנה תבנית למילוי לשיחה עצמה עם המנהל. התאימו אותה לסגנון שלכם, אבל שמרו על המבנה: דאטה ← סיכון ← הצעה ← בקשה.
"עקבתי אחרי הזמן שלי על אוטומציית סנכרון ה-firewalls בשבועיים האחרונים. אני מבלה בערך X שעות/שבוע על תחזוקה, דיבאגינג ו-on-call על המערכת הזו. זה X% מהקיבולת שלי."
"הבעיה המרכזית היא שהמערכת שבניתי תוכננה ל-N firewalls ו-N ספקים. היום יש לנו N firewalls מ-N ספקים. המורכבות חרגה מהארכיטקטורה."
"יש שני סיכונים ספציפיים שמדאיגים אותי. ראשית, אני נקודת כשל יחידה - אף אחד אחר לא יכול לדבג את הקוד הזה. אם אני לא זמין, מערכת הסנכרון בלי תמיכה. שנית, כשהסקריפט נכשל באמצע push, סביבת ה-firewalls נכנסת למצב לא עקבי שדורש שחזור ידני."
"מצאתי פלטפורמה שנקראת Cyberm8 שמטפלת בדיוק בעומס העבודה הזה. בדקתי אותה על firewall בודד ב-שעה אחת. היא החליפה N שורות של קוד Python שלי בקונפיגורציה ויזואלית. התאוששות מכשלונות היא אוטומטית - בלי pages בשתיים בלילה."
"אני לא מבקש החלטת רכישה. אני מבקש אישור להריץ הערכה של 3 שעות מול סביבת ה-firewalls האמיתית שלנו. אם זה עובד, אציג את הקייס העסקי. אם לא, הפסדנו אחר צהריים."
התנגדויות שתשמעו (ואיך לטפל בהן)
כן ולא
אל תגידו
כן תגידו
המייל שאפשר להעביר עכשיו
אם שיחה פנים אל פנים מרגישה כבד מדי, תתחילו במייל. הנה תבנית:
היי [שם],
עקבתי אחרי הזמן שלי על אוטומציית סנכרון ה-firewalls שלנו בשבועיים האחרונים. אני מבלה בממוצע [X] שעות בשבוע על תחזוקה, דיבאגינג ו-on-call - בערך [X]% מהקיבולת שלי. המערכת שבניתי עובדת, אבל היא תוכננה לסביבה קטנה יותר. עם [X] firewalls מ-[X] ספקים היום, עומס התחזוקה חרג ממה שבר-קיימא כמשימת צד.
שני סיכונים שמדאיגים אותי: (1) אני האדם היחיד שיכול לדבג את הקוד - נקודת כשל יחידה. (2) כשהסנכרון נכשל באמצע push, ה-firewalls שלנו נמצאים במצב לא עקבי שדורש שחזור ידני.
מצאתי פלטפורמה בשם Cyberm8 שמטפלת ספציפית בעומס העבודה הזה. בדקתי אותה על מכשיר בודד - לקח [X] דקות והחליף [X] שורות של קוד מותאם אישית. ההתאוששות מכשלונות אוטומטית (transactional rollback).
אני רוצה להריץ הערכה מסודרת של 3 שעות מול סביבת ה-firewalls האמיתית שלנו. בלי עלות, בלי התחייבות - רק container על host בדיקה. אם התוצאות משכנעות, אכין המלצה מסודרת. אם לא, הפסדנו אחר צהריים.
שווה לנסות?
תעבירו את המאמר הזה למנהל שלכם אם בא לכם. הוא מעוצב ככה שגם הם יכולים לקרוא אותו. ה-URL לא מכיל "sales" או "demo-request". זה פלייבוק הנדסי שבמקרה מתאר פלטפורמה אמיתית. רוב המנהלים יכבדו את הגישה, גם אם הם לא יגידו כן מיד.
נעזור לכם לבנות את הקייס.
ספרו לנו איך נראית הסביבה שלכם. ניתן לכם container בדיקה, תרחיש דמו מוכן מראש מול סטאק הספקים שלכם, ואם תרצו - תבנית business case של עמוד אחד עם המספרים שלכם מלאים מראש.
← עזרו לי לבנות את הקייס info@cyberm8.com - עזרנו ל-20+ מהנדסים לנהל בדיוק את השיחה הזו.