Chief Magazine

 

גיליון מספר 47 שנה III - יום חמישי 27 בנובמבר 2003

 המערכת:

    עורכת: דר' פלי גלקר

feli@chief.co.il

    קונספט: אלדד גלקר

eldad@chief.co.il

    מבצעים והנחות

s@marketing.co.il
    יעוץ ופרוייקטים oz@support.co.il

 

 

תוכן:

החוליה החלשה

Responding to Change

קשה באימונים - קל בקרב

 מבט לתכנות

 

"If you can dream it, you can do it."
                                                                   Walt Disney

למבקשים את הטופס שנית

 

חברות וארגונים הבוחנים מערכות גיבוי לדואר אלקטרוני

ומעוניינים להיכנס לתוכנית ה BETA ולהתנסות במוצר הגיבוי הייחודי ממשפחת BOS

מוזמנים לשלוח אלינו את טופס ההרשמה המצורף

 

p11.jpg (255082 bytes)

החוליה החלשה

 

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

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

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

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

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

"כבל חשוד: אתה החוליה החלשה - שלום !"

Data Integrity

Consulting Services

www.axafe.com

Responding to Change

 From the article by Randy Miller

 

"There are very few software development projects that don’t experience some sort of change. This change may be due to uncertainty, business climate, technology, or risk. Regardless of its source, a project will be impacted by some sort of change more often than not. Some will be impacted by so much change that it threatens the very project itself.

There are two ways to deal with this change. Resist or adapt. When a plan is involved, the natural tendency is to resist. Freeze the requirements or the software technology. Deliver the project anyway, even though it will never meet the needs of the customers. Follow the plan over all. This approach serves to prop up the ego of the person who wrote the plan but not the customers.

Plans are good things. They are just not the ultimate things. The goal of any project should be to deliver software that meets the needs of the customers. If these needs change, so must the software. Following a plan that everyone knows is unrealistic or out-of-date saps motivation. The software should change and so should the plan"

למאמר המלא

 

קשה באימונים - קל בקרב

 

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

כאשר מגיע הרגע בו יש צורך לשחזר מידע - בעיקר במערכת היצרנית - אף אחד לא רוצה להתחיל ללמוד כיצד הדברים עובדים; רוצים שהעבודה תיעשה כמה שיותר מהר!

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

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

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

בפתרונות שחזור הפשטות יקרה, מפני שמקלה על המפעיל אותו ברגעי לחץ.

 

האם כבר תרגלת שחזור השבוע ?

 

שאלות בענייני רשת ממוקדת המשכיות עסקית

שולחים בצירוף שם ומספר טלפון

לדואר אלקטרוני oz@support.co.il

 

 

 

 

 

 

 מבט לתכנות

מתוך "?Is it Just  Coincidence " של Tom Graves

 

עבור אנשים מסוימים המחשב מייצג את הכוח האולטימטיבי של דה-הומניזציה בטכנולוגיה העכשווית, על כן שווה לזכור כי מחשב הינו רק כלי. המילה האנגלית COMPUTER  מבלבלת, מפני שרוב המחשבים עושים מעט מאוד Computing , חישוב, או "תחינת מספרים" בכלל. המילה הצרפתית Ordinateur - במשמעות מילולית, "עושה סדר" מתארת טוב יותר את התהליך. מחשב, למעשה, הוא מכונה לוגית, מהירה אך טיפשית, הפועלת על פי חוקים והוראות לוגיות מסודרות ברצף אותו אנו מכנים :"תוכנה".

כל מערך חוקים בנוי במחשוב  על רבדים נוספים של חוקים: שפת תכנות, ומערכת ההפעלה תחתיה, ועוד שפת מערכת ההפעלה מתחת, וכו', עד אל תוך הלוגיקה הבנויה בקרבי המעבד, והלוגיקה הפשוטה של המתגים בשני מצבים : on & off

במונחים לוגיים, כל מה שמחשב עושה הוא "נכון". אם זה מתאים, או שימושי, זה כבר סיפור אחר...

אם להיצמד לתכונות הבסיסיות של תוצרי התכנות, ניתן לחלק אותן לחמישה מושגים:

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

עיקרון המפתח השני הינו הראיון של מתן שמות לדברים : "אם לא ידוע לך מה זה, תן לו שם".עקרון זה נלקח מן האלגברה; האות המסתורית הזו שנקראת "X", למשל...לאחר שקיבל שם, ה"כתובת" הזו מסוגלת להכיל ערך כלשהו, שיישאר קבוע או ישתנה- כמשתנה, ותהליך אחר יכול להתייחס אליו על פי שמו. שפות תכנות רבות כגון Pascal ו-C צריכות את השמות הללו כדי להיות "מוכרזות" בתוך התוכנה. שפות אחרות כגון רוב הגרסאות של Basic, מאפשרות לך לאתר שמות , אבל מתן שמות שרירותיים על פי כדאיות פראקטית משותף לכולם.  

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

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

נקודת המפתח הבאה הינה הרעיון של "אולי". החלטה לוגית, קיימת ברוב שפות התכנות כמבנה של :If...then...else,  או:

"If so - and so is true, then do this, else do that". הקונטקסט בנוי בצורה לוגית, רובד על רובד, עם כל החלטה מתקבלת באופן לוגי על קונטקסט שהוגדר מראש על ידי פקודות אחרות, פעולות אחרות. החלטות אלה הופכות ל"אינטליגנציה" הנראית של התוכנה.

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

חומר למחשבה.  המקור מומלץ

פינת הבנים:

 

 

.

תרומתו של גרי  

 
 

 

לעיון במידעון השבועי העדכני, ראה קישור:

http://www.chief.co.il/magazine

רשימת כל הגיליונות הקודמים נמצאת ב:

http://www.chief.co.il/magazine/2003/Archive.htm

 
 
     

    נא לא להשיב (reply) על הגיליון נשמח לקבל הערות והארות,

   המלצות  ובקשות  או קישורים לאתרים מעניינים לדוא"ל:

  eldad@chief-group.com או feli@chief-group.com

 
     

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

 
 
 

   כל הזכויות שמורות 1986-2003 © צ'יף יישומים ישראל בע"מ

Hit Counter