מפעילים
ניהול דייר עבור מפעילים
הפעל את מסך הגישה של המפעיל — בחר תחילה את גבול החשבון, ואז טפל בחברים, הרשאות, יעדי סביבות עבודה, מדיניות חיוב, SSO וראיות אונבורדינג ממכתבה אחת שבבעלות Console.
עודכן לאחרונה
למה משמש מסך הגישה
מסך המפעיל ב‑/tenants נושא את הכותרת Access operations ב‑Console, ואזור העבודה בתוכו הוא Customer operations desk. זהו מסלול יחיד שבבעלות Console, שבו צוותי הפלטפורמה בוחרים גבול חשבון פעם אחת, ואז מנהלים את כל לולאת האספקה: היקף גישה וזהות, חברים והרשאות, ניתוב יעד סביבת עבודה, מוכנות לחיוב, סביבות מתמשכות, ראיות Shared Drive ותצוגת שימוש.
אותו מסלול מציג למנהלי לקוחות תצוגה של שירות עצמי כדי שיוכלו לאשר את הגישה שלהם, להגיש פרטי SSO, לטפל ברשימת המשימות של האונבורדינג ולהזמין את הצוות שלהם. התוויות והפעולות הזמינות משתנות לפי התפקיד שלך: מפעילי ומנהלי פלטפורמה רואים תמיכה חוצת‑לקוחות ועבודת הגדרה מאושרת, ואילו מנהלי לקוחות רואים רק את החשבון שלהם.
השתמש בו כבקרת שיגור. אשר את גבול החשבון, שער החיוב, גישת הדייר, ניתוב היעד ומסירת השימוש לפני שלקוח מתחיל ליצור סביבות עבודה.
בחר תחילה את ההיקף
תמיד אשר את היקף הלקוח החייב בתשלום, הדייר והחבר לפני שינוי כלשהו. רוב הפעולות הן בהיקף לקוח ואוכפות את הלקוח שנבחר כאשר קיים כזה. באשכול חדש, הפעל תחילה את הבוטסטרפ ובדיקת ההיקף — הם עונים מי אתה המחובר, איזה חשבון לקוח אתה מנהל, היכן יפעלו סביבות העבודה, והאם ניתן לייחס שימוש לאותו לקוח — לפני בדיקת זרימות סביבת עבודה או חיוב במורד הזרם.
אם תוויות גישת ה‑SSO ריקות, ייתכן שעמודים במורד הזרם כמו Analytics לא יידעו באיזה היקף לקוח להשתמש. היכנס מחדש דרך SSO לפני בדיקת יצירת סביבות עבודה.
לשוניות משנה לאורך המכתבה
ה‑Customer operations desk מקבץ את עבודתו ללשוניות משנה לאורך החלק העליון של המסך. נוע ביניהן בערך בסדר הזה במהלך שיגור.
| לשונית משנה | מה אתה עושה שם |
|---|---|
| Overview | אשר את גבול הלקוח או הדייר הפעיל וקפוץ אל המסכים שמחזיקים תמיכה, סקירה, סביבות, אחסון, חיוב וביקורת. |
| Customers | רשומות לקוחות, מדיניות חיוב, אונבורדינג ומסירת API. |
| Members | רשימת חברות הלקוח והדייר. |
| Permissions | מדיניות תכונות והרשאות‑על לכל חברות. |
| Targets | ניתוב סביבת עבודה וכינויי תבניות. |
| Onboarding | רשימת משימות, הגדרת SSO, מחזור חיים והיסטוריית התראות. |
נתיבי ה‑Overview משקפים את לולאת התפעול: גישת לקוח, שינוי שנסקר, ראיית QA, מועמד סביבה, קידום וסקירת חיוב. פעולות מהירות ב‑Overview פותחות את Customers, Members, CI & Review, Environments, Shared Drive, Billing policy, Analytics ו‑Audit history.
זמינות פעולות (מפת ה‑CRUD)
תג מפת ה‑CRUD מציג אילו נתיבי יצירה, עדכון ומחיקה נגישים בהפעלה הנוכחית, ומדוע השאר אינם. קרא אותו כאשר פעולה נראית חסרה. לדוגמה, הוא מסביר שלחשבונות לקוח אין עדיין מסלול מחיקה — העבר את מחזור החיים אל suspended, offboarding או closed במקום — ושפעולות מסוימות מגודרות למפעיל מפני שהן מניעות חיוב, ייחוס או את גבול החשבון.
כמה ערכים שכדאי להכיר:
- חשבון לקוח — למפעיל בלבד, מפני שרשומת החשבון מניעה חיוב, מחזור חיים וייחוס. מנהלי לקוחות יכולים להגיש נתוני אונבורדינג אך אינם יכולים לשנות את הרשומה החייבת בתשלום.
- חברים — יצירה, עדכון ומחיקה דורשים הרשאות מנהל דייר; מסלולים בהיקף לקוח אוכפים את הלקוח שנבחר.
- מפתחות Archibot API — זמינים בשלב מסירת הלקוח. סודות גולמיים מוצגים פעם אחת.
- התראות — מנהלי לקוחות יכולים לקרוא את היסטוריית ההתראות שלהם; השליחה נשארת מגודרת למפעיל.
עזרה בתוך האפליקציה
כל חלונית נושאת פקד עזרה הקשרי. פעולת Explain access operations פותחת תיבת דו‑שיח שמשחזרת את ארבע שאלות ההגדרה ומילון מונחים בשפה פשוטה: חשבון לקוח הוא החברה החייבת בתשלום, דייר הוא הפלח של גישת Console עבור אותה חברה, יעד סביבת עבודה הוא אשכול זמן הריצה שבו פועלות סביבות העבודה, ומפתח API הוא הדרך שבה Archibot או אוטומציה קוראים ל‑API בהיקף לקוח. תיבת הדו‑שיח היא הקשר לקריאה בלבד; סגירתה מחזירה אותך לאותו היקף. השתמש בה כאשר אינך בטוח אם תווית חסרה או היקף ריק חוסמים בדיקה במורד הזרם.
לשוניות Customers ו‑onboarding
פתח את לשונית המשנה Customers כדי לטפל בחשבון יחיד. כל רשומת לקוח נושאת רצועת לשוניות משלה:
- Profile — זהות החשבון.
- Plan — מחזור חיים, ברירות מחדל ושכבת שירות.
- Onboarding — רשימת משימות והיסטוריית מחזור חיים.
- Billing — סקירת חיוב ומדיניות תמחור.
- API — גישת API בהיקף לקוח.
לשונית Onboarding פותחת את לשוניות המשנה שלה: Details (הקשר חשבון ואנשי קשר), SSO setup (שיתוף או סקירת מטא‑נתוני IdP), Checklist (רשומת השיגור המשותפת), Lifecycle (היסטוריית מצב) ו‑Notifications (היסטוריית התראות מתמשכת). סטטוס רשימת המשימות וההערות הופכים לרשומת השיגור המשותפת במקום דוא”ל או צ’אט בערוץ צדדי.
חברים והרשאות
בלשונית המשנה Members, מפעילים יכולים להזמין, ליצור, לעדכן, להעביר, להשבית ולהסיר חברים בתוך הדייר שנבחר. (מנהלי לקוחות יכולים להזמין, ליצור, לעדכן, להשבית ולהסיר, אך לא להעביר.) השתמש במנהל דייר במשורה — רוב המשתמשים צריכים להיות חברי דייר אלא אם הם מנהלים הזמנות או ראיות אונבורדינג.
לשונית המשנה Permissions פותחת את עורך Permission policies, שמגדיר גישה הנגזרת מתפקיד, הרשאות תכונה מותאמות אישית והרשאות‑על לכל חברות בהיקף שנבחר.

עבוד בעורך בשלושה צעדים:
- השתמש ב‑Policy controls וב‑Filters and search כדי לצמצם את הרשימה, ואז בחר חבר. אריחי המדדים (Role templates, Custom policies, Meta grants, Admins) מציגים כיצד ההיקף מתפלג.
- ב‑Member policy editor, בחר את Policy mode. Role template מחשב הרשאות אפקטיביות מהתפקיד והסטטוס שנבחרו; Custom grants שומר מערכי תכונות והרשאות‑על ישירות על החברות.
- החל Preset grant כחבילת התחלה, התאם הענקות בודדות במטריצת התכונות, ואז בחר Save policy. השתמש ב‑Clear selection כדי לסגת מבלי לשמור.
הענקות מוגדרות מראש מספקות חבילה ידועה שתוכל להתאים:
- Tenant admin — ניהול מלא של דייר ולקוח עם האצלה מבוקרת.
- Workspace lead — מחזור חיים של סביבת עבודה, כתיבה ל‑Shared Drive וניהול סקירת CI.
- Billing manager — Analytics, חשבוניות, תקרות הוצאה ותמחור משאבים ללא שליטה בסביבת עבודה.
- Auditor — נראות לקריאה בלבד על פני התפעול בתוספת סמכות ייצוא ביקורת.
הרשאות‑על שולטות מי רשאי להאציל תפקידים, להעניק או לבטל הרשאות, לאשר חריגים, לנהל תבניות מדיניות, לאשר גישת תמיכה, לייצא ראיות ביקורת או לאשר העלאת הרשאות חירום (break-glass). הענק אותן רק לחברויות שמנהלות מדיניות גישה. כל הענקת תכונה נשמרת לפי מזהה הרשאה יציב כך שאכיפת backend עתידית צורכת את אותה מדיניות.
יעדי סביבת עבודה וברירות מחדל
Create Workspace יכול לנתב סביבות עבודה עבור חשבון רק לאחר ש‑יעד סביבת עבודה מצורף, לכן צרף יעד לפני יצירת סביבות העבודה של הלקוח. בלשונית המשנה Targets אתה מאשר את כתובת ה‑URL של זמן הריצה של סביבת העבודה, מצב האימות של היעד, כינויי תבניות וספקי Git נתמכים. כינויי תבניות שומרים על יציבות השמות הגלויים ללקוח; שדות אסימון השירות ביעדים נשארים למפעיל בלבד.
השתמש ב‑Workspace defaults כדי להגדיר את הערכים ברמת הארגון שבהם Create Workspace צריך להתחיל עבור הלקוח הזה.
חיוב ותמחור משאבים
לשונית Billing מכסה מוכנות לחיוב, מסירת Stripe ומדיניות תמחור המשאבים. מצב החיוב הוא שער יצירת סביבת העבודה: רשום את ערוץ התשלום וסמן את החשבון כתקופת ניסיון מאושרת או מאומת לפני יצירת סביבות העבודה של הלקוח.

Resource pricing policy משכבת ברירות מחדל של פריסה עבור ה‑Analytics וחשבונאות החריגה של לקוח אחד. החלונית מציגה את מקור המדיניות, כמה מפתחות מוגדרים במפורש עבור הלקוח, ואת מפתחות ברירת המחדל הבסיסיים מתצורת הפריסה. עקוף את תנאי הלקוח כאן רק כאשר הצעת מחיר, תוכנית שירות או הסכם ארגוני משתמשים בקצבאות או בתעריפים שונים, ואז בחר Save policy.
Estimated pricing presets מספקים נקודות התחלה לשיגור שתוכל להתאים לפני תמחור:
- Pilot — קצבת התחלה לצוות יישום אחד שמאמת CI, סקירה, QA ו‑Shared Drive קטן.
- Team — קצבת עבודה לצוות לקוח פעיל עם מחזורי סקירה/QA חוזרים ושימוש בינוני ב‑Shared Drive.
- Enterprise — קצבה גדולה יותר לתכנון פריסה רב‑צוותית, QA כבד ואחסון סביבה מתמשכת גדול יותר.
השתמש ב‑Start from deployment defaults כדי לאפס את העורך. רשום את תווית גרסת מודל התמחור עבור הצעת המחיר או תיקון המדיניות. Stripe נשאר הסמכות לחשבוניות, תשלומים ורשומות הכנסה — ערכי התמחור של Console הם תנאי מפעיל או לקוח, לא מטעני ספק, ואירועי חשבונית של Stripe מעדכנים את היסטוריית התשלום באופן אוטומטי.
הגדרת SSO
מנהלי לקוחות מגישים סוג IdP, דומיינים, תביעות, קבוצות, כתובות URL לקריאה חוזרת ומשתמשי בדיקה בלשונית SSO setup כדי ש‑ISM יוכל למפות גישה בבטחה. עבור OIDC, אסוף כתובות URL לגילוי; עבור SAML, אסוף כתובות URL של מטא‑נתונים ופרטי אימות קריאה חוזרת. מפעילים סוקרים את המטא‑נתונים שהוגשו באותה לשונית. תוויות גישת SSO מגיעות מספק הזהות וקובעות אילו סקירה כללית, פעולות הגדרה והיקף לקוח Console חושף.
שמור את שתי חבילות ההערות נפרדות
- Customer-submitted details ו‑ISM launch context גלויים ללקוח. השתמש בהם להקשר שהלקוח יכול לסקור עם ISM.
- Internal operator notes הם ל‑ISM בלבד ואינם צריכים להופיע בתגובות אונבורדינג בהיקף לקוח.
בכל שדה — גלוי ללקוח או פנימי — שמור פרטי הזדהות, פרטי תשלום, מפתחות פרטיים וקישורי הזמנה בחוץ. מחזור החיים של האונבורדינג והיסטוריית ההתראות הם רשומות מתמשכות; שליחת דוא”ל נשארת מגודרת מאחורי שולח ההתראות.
מדריכים קשורים
- תפקידי גישה לגבולות התפקידים שמסך זה אוכף.
- הגדרת מנהל לקוח למסלול השירות העצמי הפונה ללקוח.
- מרכז התפעול לאותות CI, QA, בוטים וקיבולת בזמן אמת.
- סביבות מתמשכות ו‑CI Review לנתיבי הסקירה‑אל‑קידום.
- שימוש וחיוב לאופן שבו תצוגת השימוש ורשומות Stripe נפגשות עם מדיניות התמחור שאתה מגדיר כאן.
הושלם כאשר
- היקף הלקוח והדייר שנבחר נכון לפני כל שינוי.
- הקשר הגלוי ללקוח והערות מפעיל פנימיות נשמרים בחבילות נפרדות משלהם.
- יעד סביבת עבודה מצורף לפני שלקוח יוצר סביבות עבודה.
- פרטי הזדהות, פרטי תשלום, מפתחות פרטיים וקישורי הזמנה נשארים מחוץ לכל שדה.