CSP Networks
לפני שמחליפים את רשת התקשורת: 10 דברים שכדאי לבדוק
מדריך מעשי להגדרת דרישות, מיפוי התשתית, שרידות, אלחוט, ענן, אבטחה ועלות כוללת לפני יציאה לפרויקט תקשורת.
החלפת תשתית תקשורת ארגונית היא החלטה שמתקבלת בדרך כלל אחת למספר שנים, אך משפיעה על הארגון הרבה אחרי שהפרויקט הסתיים. לפני שיוצאים למכרז או מתחילים להשוות בין פתרונות, כדאי לבחון את התשתית בצורה רחבה ושיטתית.
שירותים הקשורים לנושא
- רשתות תקשורת ארגוניות - ארכיטקטורה לרשתות LAN, WAN, SD-WAN ו-Wi-Fi - ביצועים, סגמנטציה, שרידות ואבטחה על בסיס דרישות מדידות.
- מכרזים טכנולוגיים וליווי רכש - דרישות מדידות, מנגנוני הוכחה וקבלה, SLA, מודל תמחור, מטריצת השוואה וליווי הבחירה והיישום.
- ייעוץ אסטרטגי וארכיטקטורה טכנולוגית - ארכיטקטורת יעד, מפת דרכים, ניתוח חלופות, סיכונים והצדקת השקעה לפני פרויקט משמעותי.
1. להתחיל בדרישות ולא בציוד
השאלה הראשונה אינה איזה מתג לרכוש. צריך להתחיל במספר האתרים, המשתמשים והמערכות הצפויים להתחבר, בשירותים הקריטיים, בדרישות הזמינות ובשינויים הצפויים בשנים הקרובות. רק לאחר שהדרישות ברורות נכון לתרגם אותן לארכיטקטורה ולציוד.
2. להבין את המצב הקיים
לפני תכנון רשת חדשה נדרש מיפוי מדויק של הטופולוגיה, הקישורים, הציוד הפעיל, הכתובות, רשתות המשנה, מנגנוני הניתוב, התלויות בין המערכות והחיבורים לשירותים חיצוניים. לעיתים מתגלות בשלב הזה תלויות שלא תועדו במשך שנים.
3. לבדוק נקודות כשל אמיתיות
שני מתגים אינם בהכרח שרידות, ושני קישורים שמגיעים דרך אותו תוואי אינם בהכרח יתירות. גם שני מרכזי נתונים יכולים להיות תלויים ברכיב משותף שיוצר נקודת כשל יחידה. שרידות צריכה להיבדק מקצה לקצה ולא רק ברמת רכיב בודד.
4. לתכנן את הצמיחה
יש להביא בחשבון גידול בכמות המשתמשים, ציוד הקצה, המצלמות, מערכות הבניין, שירותי הענן, עומסי הווידאו ומערכות חדשות. עם זאת, אין צורך לרכוש מראש קיבולת מוגזמת. המטרה היא לבנות ארכיטקטורה שניתן להרחיב באופן מתוכנן.
5. לבחון את הרשת האלחוטית בנפרד
תכנון נכון אינו מבוסס רק על מספר נקודות הגישה. יש להתייחס לכיסוי, צפיפות משתמשים, הפרעות, קיבולת, סוגי מכשירים, המבנה הפיזי והיישומים שהעובדים מפעילים. הצבה ללא תכנון מתאים עלולה ליצור רשת שנראית חזקה על הנייר אך מספקת חוויית שימוש לא יציבה.
6. לא להתעלם מהענן
גם כאשר רוב המערכות פועלות במרכז הנתונים המקומי, חלק משמעותי מהשירותים הארגוניים כבר מגיע מהאינטרנט ומהענן. לכן תכנון הרשת הרחבה צריך להביא בחשבון גם את הדרך שבה משתמשים מגיעים לשירותי ענן, למערכות תוכנה כשירות ולמרכזי נתונים חיצוניים.
7. לשלב אבטחה בתוך הארכיטקטורה
חלוקה נכונה לאזורים, בקרת גישה, הפרדת מערכות, זהויות, ניטור ומדיניות תקשורת צריכים להיות חלק מהארכיטקטורה מהשלב הראשון. כך ניתן ליישם אבטחה בלי להפוך את הרשת למסובכת מדי לתפעול.
8. לחשוב על היום שאחרי ההקמה
פרויקט שמסתיים בהצלחה ביום העלייה לאוויר הוא רק תחילת חיי המערכת. כדאי לבחון מראש כיצד יתבצעו ניטור, גיבוי תצורות, עדכוני תוכנה, טיפול בתקלות, ניהול הרשאות ותיעוד שינויים. ארכיטקטורה טובה צריכה להיות לא רק מתקדמת אלא גם ניתנת לניהול.
9. להשוות עלות כוללת ולא רק מחיר רכישה
הצעה זולה יותר ביום הרכישה אינה בהכרח החלופה הזולה לאורך חיי המערכת. יש לבחון גם רישוי, תמיכה, תחזוקה, מודולי הרחבה, מנויים, כוח אדם, צריכת חשמל ועלויות שדרוג עתידיות. השוואה נכונה מתבססת על עלות כוללת למספר שנים.
10. לשמור על עצמאות בהחלטה
יצרנים ואינטגרטורים הם חלק חשוב בכל פרויקט תשתיות, אך לכל ספק יש באופן טבעי סל פתרונות שהוא מייצג. בפרויקטים משמעותיים כדאי שהגדרת הצרכים, הארכיטקטורה ומסמכי המכרז יבוצעו מנקודת המבט של הארגון. כך ניתן לקיים תהליך תחרותי ולהשוות בין פתרונות בצורה מקצועית ושקופה.
לסיכום
פרויקט תקשורת מוצלח אינו מתחיל בבחירת דגם של מתג או נתב, אלא בהבנת הארגון. תשתית שתוכננה על בסיס הדרישות האמיתיות, עם התייחסות לשרידות, אבטחה, ענן, תפעול וגידול עתידי, יכולה לשרת את הארגון לאורך שנים ולהפחית השקעות בלתי מתוכננות.