לפעמים אפשר להמשיך עם המערכת הקיימת אחרי קליטה מסודרת. לפעמים צריך קודם בדיקה עמוקה יותר, תיקון תשתיות, השלמת גיבויים או אפילו החלטה שחלק מהמערכת כבר לא כדאי לתחזק כפי שהוא.המדריך הזה מיועד לבעלי עסקים שיש להם אפליקציה, מערכת ווב, אתר מורכב או מוצר פנימי קיים, ורוצים להעביר את התחזוקה למפתח חדש בלי לאבד שליטה על הקוד, ההרשאות והידע.
1. האם צריך להתחיל מאפס?
לא ניתן להבטיח מראש שלא יהיה צורך בשכתוב. ההחלטה תלויה במצב הקוד, התשתיות, בסיס הנתונים, התיעוד, רמת התלות בספק הקודם והיכולת לבנות ולהריץ את המוצר בלי לסכן משתמשים.אם יש גישה מסודרת לקוד, סביבת בדיקות, תהליך build ופריסה ברור וגיבוי עדכני, הרבה פעמים אפשר להמשיך בהדרגה. אם חסרים חלקים קריטיים או שהמערכת שבירה מאוד, ייתכן שצריך קודם ייצוב, שדרוג או החלפה של חלקים.
- האם יש גישה למאגר הקוד ולגרסה האחרונה?
- האם אפשר להפעיל סביבת פיתוח או בדיקות?
- האם ידוע איפה המערכת מאוחסנת ואיך היא נפרסת?
- האם קיימות תקלות, תלויות ישנות או חסימות שמונעות תחזוקה רגילה?
2. אילו נכסים צריך להעביר
העברת תחזוקה אינה רק העברת קובץ אפיון. צריך לוודא שכל הנכסים שמפעילים את המוצר נמצאים בשליטת העסק או נגישים בצורה מסודרת למפתח החדש.כדאי לרכז רשימה אחת של מה קיים, מי הבעלים של כל חשבון, מי מנהל אותו היום, ומה הדרך הנכונה לתת גישה בלי לחשוף סיסמאות מיותרות.
- מאגרי קוד, ענפים פעילים והרשאות ל-Git או לכלי ניהול הקוד.
- תשתיות אחסון, שרתים, שירותי ענן, לוגים וסביבות פיתוח או בדיקות.
- בסיסי נתונים, גיבויים, כלי ניהול נתונים והרשאות גישה.
- דומיין, DNS, תעודות אבטחה והגדרות מייל אם הן קשורות למוצר.
- חשבונות חנויות אפליקציות, אם מדובר באפליקציית מובייל.
- שירותי צד שלישי כמו סליקה, מיילים, SMS, מפות, אנליטיקות או תמיכה.
- תהליך build ופריסה: איך יוצרים גרסה ואיך מעלים אותה לאוויר.
- תיעוד קיים, אפיונים, תרשימים, החלטות מוצר ורשימת תקלות פתוחות.
3. איך מעבירים הרשאות בלי להעביר סיסמאות במסמך
לא כדאי להעביר סיסמאות בתוך מסמך אפיון, גיליון משותף או הודעת WhatsApp. הדרך הנכונה היא להשתמש במנגנוני הזמנה של כל שירות: משתמש חדש, תפקיד מתאים והרשאה שאפשר לבטל בהמשך.סודות טכניים כמו מפתחות API, מפתחות פריסה, סיסמאות למסדי נתונים וטוקנים צריכים להיות מנוהלים בכלי מתאים לניהול סודות או בהגדרות הסביבה של שירות האחסון, ולא כטקסט חופשי במסמכים.
- תנו הרשאה לפי צורך: קריאה, פיתוח, ניהול או חיוב, ולא תמיד הרשאת בעלים.
- החליפו סודות ישנים אם לא ברור מי נחשף אליהם בעבר.
- בדקו מי עדיין מחזיק גישה אחרי סיום העבודה עם הספק הקודם.
- תעדו איפה מנוהלים הסודות בלי לכתוב את הערכים עצמם במסמך.
4. מה לבדוק לפני שמסיימים עם הספק הקודם
לפני שסוגרים את העבודה עם הספק הקודם, כדאי לוודא שהעסק מחזיק בגישה לנכסים המרכזיים ולא רק בתוצר שעובד כרגע. אחרי שהקשר מסתיים, קשה יותר להשלים ידע, לקבל הזמנות לחשבונות או להבין תהליך פריסה ידני.מומלץ לבקש חפיפה מסודרת לפני שהקשר עם הספק מסתיים.
- וודאו שהבעלות או ההרשאה לחשבונות המרכזיים נמצאת אצל העסק.
- בקשו הסבר על תהליך build ופריסה, כולל סביבות בדיקות ופרודקשן.
- בדקו שיש גיבוי עדכני ושמישהו יודע איך לשחזר אותו.
- אספו תיעוד, החלטות מוצר, תרשימים ורשימת תקלות פתוחות.
- סגרו הרשאות שאינן נדרשות רק אחרי שהגישה החדשה נבדקה.
5. בדיקת מצב ראשונית לפני שלוקחים אחריות
לפני שמבטיחים תחזוקה שוטפת, צריך להבין אם המוצר ניתן לתחזוקה. בדיקה ראשונית עוזרת לזהות אם הבעיה היא רק חוסר סדר, או שיש חסמים עמוקים יותר שמחייבים טיפול לפני שממשיכים לפתח.הבדיקה לא חייבת לפתור הכול ביום אחד. המטרה היא לקבל תמונה ברורה: מה עובד, מה שביר, מה חסר, ומה מסוכן לגעת בו בלי גיבוי או סביבת בדיקות.
- יכולת לבנות, להריץ ולבדוק את הפרויקט בסביבה שאינה פרודקשן.
- תלות בספק הקודם: ידע שנמצא רק אצלו, חשבונות שבבעלותו או תהליכים ידניים.
- גרסאות של ספריות, שפות, מסדי נתונים ושירותים חיצוניים.
- תקלות קריטיות, אזורים שבירים ותהליכים שמשתמשים תלויים בהם.
- מצב גיבויים, שחזור נתונים ותוכנית פעולה במקרה של תקלה.
- פערים בתיעוד, הרשאות חסרות או חלקים שלא ברור מי אחראי עליהם.
6. איך עושים מעבר מדורג
מעבר טוב לא מתחיל בשינוי גדול בפרודקשן. קודם מוודאים שיש דרך לבדוק ולחזור אחורה, ורק אז מבצעים שינוי קטן.
- הקימו או אשרו סביבת בדיקות לפני שינוי משמעותי.
- וודאו שיש גיבוי עדכני ותהליך שחזור שמישהו יודע לבצע.
- הכינו תוכנית חזרה למצב קודם במקרה שגרסה חדשה נכשלת.
- בדקו תהליכים מרכזיים כמו הרשמה, התחברות, תשלום, יצירת הזמנה, הודעות, דוחות או מסכי ניהול.
- התחילו בשינוי קטן או תיקון מוגבל לפני פיתוח גדול.
- תעדו מה נבדק, מה נמצא תקין ומה דורש טיפול בהמשך.
7. מה עושים כשחלק מהקוד או הגישות חסרים
אם חסרים קוד, גישה לשרת, חשבון חנות או תיעוד, לא מניחים שמותר לעקוף הגנות או להיכנס למערכת בדרך לא מורשית. מתחילים ממה שנמצא בשליטת העסק: חשבונות רשמיים, דומיין, DNS, חנויות, ספקי ענן, גיבויים ומסמכים משפטיים או תפעוליים.לפעמים אפשר לשחזר חלק מהתמונה מתוך חשבונות קיימים, גיבויים, גרסאות פרודקשן או תיעוד. לפעמים צריך לפנות לספק הקודם, לספקי התשתית או לייעוץ משפטי/תפעולי מתאים לפני שמבצעים שינוי טכני.
- בודקים אם קיימים גיבויים, חבילות build או תיעוד שיכולים לעזור.
- מפרידים בין מה שאפשר לתחזק עכשיו לבין מה שדורש שחזור או בנייה מחדש.
- מתעדים סיכונים לפני שינוי בפרודקשן.
8. מה יכולה לכלול בדיקת כניסה לתחזוקה
בדיקת כניסה לתחזוקה היא תהליך קצר יחסית שמטרתו להבין את מצב המוצר לפני התחייבות לעבודה שוטפת. היא אינה מבטיחה שהכול תקין, אלא מספקת בסיס להחלטה: מה אפשר לתחזק, מה מסוכן, ומה צריך להסדיר קודם.
- מפת קוד, תשתיות, בסיסי נתונים ושירותי צד שלישי.
- סטטוס build והרצה: מה עובד, מה נכשל ומה חסר.
- רשימת הרשאות וסודות שצריך להסדיר או להחליף.
- בדיקת גיבויים וסביבת בדיקות.
- סיכונים שמונעים תחזוקה בטוחה או פריסה רגועה.
- תוכנית כניסה מדורגת עם משימות ראשונות וסדר עדיפויות.
9. מה לכלול בחודש התחזוקה הראשון
החודש הראשון לא צריך להיות רק רשימת פיצ'רים. בדרך כלל נכון לשלב בין ייצוב, השלמת ידע, טיפול בתקלות דחופות ותכנון המשך העבודה.אם הכול תקין, אפשר להתחיל גם משימות פיתוח. אם מתגלים חסמים, עדיף לטפל קודם בדברים שמאפשרים תחזוקה בטוחה: גישה, גיבויים, תהליך פריסה ותיעוד בסיסי.
- מיפוי קוד, תשתיות, חשבונות, סביבות ותהליכי פריסה.
- סידור הרשאות והחלפת סודות שאינם מנוהלים נכון.
- בדיקת גיבויים ותהליכי שחזור בסיסיים.
- טיפול בתקלות קריטיות שמשפיעות על משתמשים או על העסק.
- הקמת רשימת משימות מסודרת לפי דחיפות וערך.
- תכנון גרסה קטנה או שיפור ראשון שאפשר לבדוק בבטחה.
10. מה משפיע על היקף העבודה
אין היקף קבוע שמתאים לכל מערכת. מוצר קטן עם קוד מסודר וגישה מלאה יכול להיקלט מהר יותר ממערכת גדולה בלי תיעוד, עם תלויות ישנות או עם כמה ספקים חיצוניים.
- גודל המערכת ומספר האפליקציות, השירותים או ממשקי הניהול.
- איכות הקוד, רמת התיעוד והיכולת להריץ בדיקות.
- מספר האינטגרציות והשירותים החיצוניים שהמוצר תלוי בהם.
- מצב התשתיות, הגיבויים, ההרשאות ותהליך הפריסה.
- דחיפות התקלות, משתמשים פעילים, גרסה קרובה או חנויות אפליקציות.
- האם ממשיכים לתחזק, משדרגים בהדרגה או מתכננים החלפה של חלקים.
דוגמה לתוכנית מעבר
מעבר קצר ומבוקר למפתח חדש
- שבוע ראשון: קבלת גישה למאגר הקוד, תשתיות, בסיס נתונים, חנויות ושירותי צד שלישי באמצעות הזמנות מסודרות.
- בדיקה ראשונית: הרצת הפרויקט בסביבת בדיקות, בדיקת build, סקירת תהליך הפריסה ומיפוי תקלות פתוחות.
- ייצוב: השלמת גיבוי, בדיקת שחזור בסיסית, החלפת סודות רגישים וסגירת הרשאות שאינן נדרשות.
- משימה ראשונה: תיקון קטן או שיפור מוגבל, עם בדיקה ותוכנית חזרה לפני עלייה לאוויר.
- המשך: תיעדוף משימות לחודש הקרוב לפי דחיפות, ערך וסיכון.
רשימת הכנה להעברת תחזוקה
גם אם אין לכם את כל הפרטים, הרשימה הזו עוזרת להבין מה צריך לאסוף לפני שמפתח חדש נכנס למערכת קיימת.- קישור למאגר הקוד והסבר איזו גרסה נמצאת בפרודקשן.
- רשימת חשבונות ותשתיות: אחסון, בסיס נתונים, דומיין, DNS וחנויות.
- רשימת שירותי צד שלישי שהמערכת משתמשת בהם.
- תיאור קצר של תהליך build ופריסה, אם קיים.
- גישה לסביבת בדיקות או החלטה שצריך להקים אחת.
- מצב גיבויים ומי יודע לשחזר אותם.
- רשימת תקלות דחופות ומשימות פתוחות.
- פרטי איש קשר אצל הספק הקודם, אם יש צורך בחפיפה.
שאלות נפוצות
האם תמיד אפשר להמשיך בלי כתיבה מחדש?
לא תמיד. קודם בודקים את מצב הקוד, התשתיות, הגיבויים, ההרשאות והתקלות. אם המערכת יציבה מספיק, אפשר להמשיך ממנה. אם יש חסמים כבדים, יכול להיות שצריך תיקון תשתיות, שדרוג הדרגתי או החלפה של חלקים.
מה עושים אם הספק הקודם לא משתף פעולה?
מתחילים ממה שנמצא בשליטת העסק: חשבונות, דומיין, חנויות, אחסון, גיבויים ומאגרי קוד. אם חסרים נכסים קריטיים, צריך להבין משפטית ותפעולית איך משיבים גישה לפני שמתחילים שינוי טכני.
האם צריך לתת למפתח החדש הרשאת בעלים לכל החשבונות?
לא בהכרח. עדיף לתת הרשאות לפי צורך דרך מנגנוני הזמנה, ולשמור הרשאות בעלים אצל העסק. במקומות שבהם נדרשת הרשאה גבוהה, כדאי להגדיר אותה במודע ולתעד למה היא נדרשת.
אפשר להתחיל מפיתוח פיצ'רים חדשים מיד?
לפעמים כן, אבל רק אחרי בדיקה בסיסית שמראה שאפשר לבנות, לבדוק ולפרוס בבטחה. אם אין סביבת בדיקות, אין גיבוי או אין תהליך פריסה ברור, עדיף לסדר את זה לפני פיצ'ר גדול.
כמה זמן לוקחת קליטה של מערכת קיימת?
זה תלוי בגודל המערכת, איכות הקוד, מצב התיעוד, מספר האינטגרציות, זמינות הגישות ודחיפות התקלות. לא נכון לקבוע זמן קבוע בלי לראות את מצב המוצר.
רוצים לבדוק מערכת קיימת לפני מעבר תחזוקה?
אפשר לשלוח תיאור קצר של המוצר, מה כבר קיים ומה הכי דחוף לכם לפתור. נתחיל מבדיקה ראשונית ונאמר אם נכון להמשיך על בסיס המערכת הקיימת או שצריך בירור עמוק יותר.רוצים לבדוק מערכת קיימת לפני מעבר תחזוקה?
אפשר לשלוח תיאור קצר של המוצר, מה כבר קיים ומה הכי דחוף לכם לפתור. נתחיל מבדיקה ראשונית ונאמר אם נכון להמשיך על בסיס המערכת הקיימת או שצריך בירור עמוק יותר.