וואָס איז DevOps

די דעפֿיניציע פון ​​​​DevOps איז זייער קאָמפּליצירט, אַזוי מיר האָבן צו אָנהייבן די דיסקוסיע וועגן עס ווידער יעדער מאָל. עס זענען אַ טויזנט אויסגאבעס אויף דעם טעמע אויף Habré אַליין. אָבער אויב איר לייענען דעם, איר מיסטאָמע וויסן וואָס DevOps איז. ווייל איך בין נישט. העלא מיין נאמען איז אלעקסאנדער טיטאוו (@אָסמינאָג), און מיר וועלן נאָר רעדן וועגן DevOps און איך וועל טיילן מיין דערפאַרונג.

איך'ווע שוין טראכטן פֿאַר אַ לאַנג צייַט וועגן ווי צו מאַכן מיין דערציילונג נוציק, אַזוי עס וועט זיין אַ פּלאַץ פון פראגעס דאָ - די וואָס איך פרעגן זיך און די וואָס איך פרעגן די קלייאַנץ פון אונדזער פירמע. דורך ענטפֿערן די שאלות, פארשטאנד ווערט בעסער. איך וועל זאָגן איר וואָס DevOps איז דארף פֿון מיין פונט פון מיינונג, וואָס עס איז, ווידער, פֿון מיין פונט פון מיינונג, און ווי צו פֿאַרשטיין אַז איר מאַך צו DevOps ווידער פֿון מיין פונט פון מיינונג. די לעצטע פונט וועט זיין דורך שאלות. דורך ענטפֿערן זיי פֿאַר זיך, איר קענען פֿאַרשטיין צי דיין פירמע איז מאָווינג צו DevOps אָדער צי עס זענען פּראָבלעמס אין עטלעכע וועג.

אין איין מאָל איך איז ריידינג די כוואליעס פון מערדזשערז און אַקוואַזישאַנז. ערשטער, איך געארבעט פֿאַר אַ קליין סטאַרטאַפּ גערופן Qik, דעמאָלט עס איז געקויפט דורך אַ ביסל גרעסערע פירמע גערופן Skype, וואָס איז געווען געקויפט דורך אַ ביסל גרעסערע פירמע גערופן מייקראָסאָפֿט. אין דעם מאָמענט איך אנגעהויבן צו זען ווי דער געדאַנק פון DevOps איז געווען טראַנספאָרמינג אין פאַרשידענע גרייס קאָמפּאַניעס. דערנאָך האָב איך זיך פֿאַראינטערעסירט צו קוקן אויף DevOps פֿון אַ מאַרק שטאַנדפּונקט, און איך און מײַנע קאָלעגעס האָבן געגרינדעט די פירמע עקספּרעסס 42. שוין 6 יאָר מיר באַוועגן זיך מיט די כוואַליעס פֿונעם מאַרק.

צווישן אנדערע זאכן, איך בין איינער פון די אָרגאַנייזערז פון די DevOps מאָסקווע קהל און דער אָרגאַניזאַטאָר פון DevOps-Days 2017, אָבער איך האָב נישט אָרגאַניזירט 2018. עקספּרעסס 42 אַרבעט מיט פילע קאָמפּאַניעס. מיר וואַקסן DevOps דאָרט, וואַך ווי דאָס כאַפּאַנז, ציען קאַנקלוזשאַנז, אַנאַלייז, זאָגן אַלעמען אונדזער קאַנקלוזשאַנז און באַן מענטשן אין DevOps פּראַקטיסיז. אין אַלגעמיין, מיר טאָן אונדזער בעסטער צו פאַרגרעסערן אונדזער דערפאַרונג און עקספּערטיז אין דעם אַכטונג.

פארוואס DevOps

דער ערשטער קשיא וואָס כאַנץ אַלעמען און שטענדיק איז - וואָס? פילע מענטשן טראַכטן אַז DevOps איז בלויז אָטאַמיישאַן אָדער אַ ענלעך זאַך וואָס יעדער פירמע האט שוין.

- מיר האָבן קעסיידערדיק ינטעגראַטיאָן - דאָס מיטל אַז מיר האָבן שוין דעוואָפּס, און וואָס איז אַלע די שטאָפּן דארף? זיי האָבן שפּאַס אין אויסלאנד, אָבער זיי האַלטן אונדז פון ארבעטן!

איבער 9 יאָר פון אַנטוויקלונג פון די קהל און מעטאַדאַלאַדזשי, עס איז שוין קלאָר אַז דאָס איז נאָך נישט פֿאַרקויף פינקלען, אָבער עס איז נאָך נישט גאָר קלאָר וואָס עס איז דארף. ווי קיין געצייַג און פּראָצעס, DevOps האט ספּעציפיש גאָולז אַז עס לעסאָף אַטשיווז.

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

אין פּרינציפּ, אַלץ אין IT זאָל זיין געבויט לויט דעם צוגאַנג. דאָ עס איז געניצט אויסשליסלעך צו אָטאַמייט פּראַסעסאַז.

אָטאַמיישאַן טוט נישט טוישן אָפט, ווייַל ווען אַ פירמע גייט אַראָפּ אַ געזונט-טראָדאַן רוט, וואָס איז דאָרט צו טוישן? עס אַרבעט - טאָן ניט פאַרבינדן עס. איצט אַפּראָוטשיז אין דער וועלט זענען טשאַנגינג, און דער איינער גערופן אַגילע סאַגדזשעסץ אַז סוף פונט ב איז נישט גלייך קענטיק.

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

די סטראַטעגיע איז דעמאַנסטרייטיד דורך אַ טשיקאַווע פירמע וואָס איך לעצטנס געלערנט וועגן. One Box Shave איז אַ אַבאָנעמענט עקספּרעס דינסט פֿאַר רייזער און סטרושקע אַקסעסעריז אין אַ קעסטל. זיי וויסן ווי צו קאַסטאַמייז זייער "קעסטל" פֿאַר פאַרשידענע קלייאַנץ. דאס ווערט געטון דורך א געוויסע סאפטוועיר, וואס שיקט דאן דעם באפעל צו די קארעאישע פאבריק וואס פראדוצירט די סחורה.

דעם פּראָדוקט איז געקויפט דורך ונילעווער פֿאַר $ 1 ביליאָן. עס איצט קאַמפּיץ מיט דזשילעט און האט אַוועקגענומען אַ באַטייטיק טיילן פון קאָנסומערס אין די אמעריקאנער מאַרק. One Box Shave זאָגן:

— 4 בליידס? זענט איר עמעס? פארוואס טאָן איר דאַרפֿן דאָס - עס טוט נישט פֿאַרבעסערן די קוואַליטעט פון די גאָלן. א ספּעציעל אויסגעקליבן קרעם, גערוך און אַ הויך-קוואַליטעט רייזער מיט צוויי בלאַדעס סאָלווע פיל מער פּראָבלעמס ווי די נאַריש 4 דזשילעט בלאַדעס! וועלן מיר באַלד באַקומען צו 10?

אזוי ענדערט זיך די וועלט. ונילעווער פאָדערן אַז זיי האָבן אַ קיל עס סיסטעם וואָס אַלאַוז איר צו טאָן דאָס. אין די סוף עס קוקט ווי אַ באַגריף צייט-צו-מאַרק, װא ם קײנע ר הא ט שוי ן ניש ט גערעדט .

די פונט פון צייט-צו-מאַרק איז נישט ווי אָפט מיר צעוויקלען. איר קענען אָפט צעוויקלען, אָבער די מעלדונג סייקאַלז וועט זיין לאַנג. אויב דריי-חודש מעלדונג סייקאַלז זענען סופּעראַמפּאָוזד אויף יעדער אנדערע, שיפטינג זיי דורך אַ וואָך, עס טורנס אויס אַז די פירמע סימז צו זיין דיפּלויד אַמאָל אַ וואָך. און פון דעם געדאַנק צו די לעצט ימפּלאַמענטיישאַן עס נעמט 3 חדשים.

צייט-צו-מאַרק איז וועגן מינאַמייזינג די צייט פון געדאַנק צו לעצט ימפּלאַמענטיישאַן.

אין דעם פאַל, ווייכווארג ינטעראַקץ מיט די מאַרק. דאָס איז ווי די One Box Shave וועבזייטל ינטעראַקץ מיט דעם קליענט. זיי טאָן ניט האָבן סיילזפּיפּאַל - נאָר אַ וועבזייטל ווו וויזאַטערז גיט און לאָזן וויל. אַקקאָרדינגלי, עפּעס נייַ מוזן קעסיידער אַרייַנגעשיקט אויף דעם פּלאַץ און דערהייַנטיקט אין לויט מיט וויל. למשל, אין דרום קארעע גאָלן זיי אַנדערש ווי אין רוסלאַנד, און זיי ווי דער רייעך ניט פון סאָסנע, אָבער, למשל, פון קעראַץ און וואַניל.

זינט עס איז נייטיק צו געשווינד טוישן די אינהאַלט פון דעם פּלאַץ, ווייכווארג אַנטוויקלונג ענדערונגען זייער. דורך ווייכווארג מיר מוזן געפֿינען אויס וואָס דער קליענט וויל. ביז אַהער, מיר געלערנט דעם דורך עטלעכע ראָונדאַוט וועגן, למשל, דורך געשעפט פאַרוואַלטונג. דערנאָך מיר דיזיינד עס, שטעלן די רעקווירעמענץ אין די IT סיסטעם, און אַלץ איז געווען קיל. איצט עס איז אַנדערש - ווייכווארג איז דיזיינד דורך אַלעמען וואס איז ינוואַלווד אין דעם פּראָצעס, אַרייַנגערעכנט ענדזשאַנירז, ווייַל דורך טעכניש ספּעסאַפאַקיישאַנז זיי לערנען ווי דער מאַרק אַרבעט און אויך טיילן זייער ינסייץ מיט די געשעפט.

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

אין 1968, אַ וויזשאַנערי באָכער, Melvin Conway, פארמולירט די פאלגענדע געדאַנק.

די אָרגאַניזאַציע וואָס קריייץ די סיסטעם איז קאַנסטריינד דורך אַ פּלאַן וואָס רעפּליקייץ די קאָמוניקאַציע סטרוקטור פון דער אָרגאַניזאַציע.

אין מער דעטאַל, צו פּראָדוצירן סיסטעמען פון אַ אַנדערש טיפּ, איר מוזן אויך האָבן אַ קאָמוניקאַציע סטרוקטור אין אַ פירמע פון ​​​​אַ אַנדערש טיפּ. אויב דיין קאָמוניקאַציע סטרוקטור איז העכסט כייעראַרקאַקאַל, דאָס וועט נישט לאָזן איר צו שאַפֿן סיסטעמען וואָס קענען צושטעלן אַ זייער הויך צייט-צו-מאַרק גראדן.

לייענען וועגן קאָנווייַ ס געזעץ איינער קענען דורך לינקס. עס איז וויכטיק צו פֿאַרשטיין די דעוואָפּס קולטור אָדער פילאָסאָפיע ווייַל דער בלויז זאַך וואָס פאַנדאַמענטאַלי ענדערונגען אין DevOps איז די סטרוקטור פון קאָמוניקאַציע צווישן טימז.

פֿון אַ פּראָצעס פונט פון מיינונג, איידער DevOps, אַלע סטאַגעס: אַנאַליטיקס, אַנטוויקלונג, טעסטינג, אָפּעראַציע, זענען געווען לינעאַר.
אין דעם פאַל פון DevOps, אַלע די פּראַסעסאַז פאַלן סיימאַלטייניאַסלי.

צייט-צו-מאַרק איז דער בלויז וועג עס קענען זיין געטאן. פֿאַר מענטשן וואָס האָבן געארבעט אין די אַלט פּראָצעס, דאָס קוקט אַ ביסל קאָסמיש, און בכלל אַזוי-אַזוי.

אַזוי וואָס טאָן איר דאַרפֿן DevOps?

פֿאַר דיגיטאַל פּראָדוקט אַנטוויקלונג. אויב דיין פירמע האט נישט אַ דיגיטאַל פּראָדוקט, DevOps איז ניט דארף - דאָס איז זייער וויכטיק.

DevOps מנצח די גיכקייַט לימיטיישאַנז פון סאַקווענטשאַל ווייכווארג פּראָדוקציע. אין עס אַלע פּראַסעסאַז פאַלן סיימאַלטייניאַסלי.

שוועריקייט ינקריסיז. ווען DevOps יוואַנדזשאַליסץ זאָגן איר אַז עס וועט מאַכן עס גרינגער פֿאַר איר צו באַפרייַען ווייכווארג, דאָס איז ומזין.

מיט DevOps, די טינגז וועט נאָר ווערן מער קאָמפּליצירט.

אויף דער קאָנפֿערענץ אין די Avito שטיין, איר קען זען ווי עס איז געווען צו צעוויקלען אַ דאָקקער קאַנטיינער - אַן אַנריליסטיק אַרבעט. די קאַמפּלעקסיטי ווערט פּראָוכיבאַטיוו; איר האָבן צו דזשאַגאַל פילע באַללס אין דער זעלביקער צייט.

DevOps גאָר ענדערונגען דעם פּראָצעס און אָרגאַניזאַציע אין די פירמע - מער גענוי, עס איז נישט DevOps וואָס ענדערונגען, אָבער די דיגיטאַל פּראָדוקט. צו קומען צו DevOps, איר נאָך דאַרפֿן צו גאָר טוישן דעם פּראָצעס.

פראגעס פֿאַר אַ מומכע

וואס האסטו? פֿראגן וואָס איר קענען פרעגן זיך בשעת איר אַרבעט אין אַ פירמע און אַנטוויקלען זיך ווי אַ מומכע.

צי איר האָבן אַ סטראַטעגיע פֿאַר קריייטינג אַ דיגיטאַל פּראָדוקט? אויב עס איז, דאָס איז שוין גוט. דאָס מיינט אַז דיין פירמע איז מאָווינג צו DevOps.

איז דיין פירמע שוין קריייטינג אַ דיגיטאַל פּראָדוקט? דעם מיטל אַז איר קענען העכערונג אן אנדער מדרגה העכער און טאָן די טינגז מער ינטערעסטינגלי - ווידער פֿון אַ דעוואָפּס פונט פון מיינונג. איך רעד נאר פון דעם שטאנדפונקט.

איז דיין פירמע איינער פון די מאַרק פירער אין די דיגיטאַל פּראָדוקט נישע? Spotify, Yandex, Uber זענען קאָמפּאַניעס וואָס זענען איצט אין די שפּיץ פון טעקנאַלאַדזשיקאַל פּראָגרעס.

פרעגן זיך די פֿראגן, און אויב אַלע די ענטפֿערס זענען ניין, אפֿשר איר זאָל נישט טאָן DevOps אין דעם פירמע. אויב די טעמע פון ​​DevOps איז טאַקע טשיקאַווע פֿאַר איר, אפֿשר ... איר זאָל מאַך צו אן אנדער פירמע? אויב דיין פירמע וויל צו גיין אין DevOps, אָבער איר האָט געענטפערט "ניין" צו אַלע די פֿראגן, דאָס איז ווי אַ שיין ריינאַסער וואָס וועט קיינמאָל טוישן.

אָרגאַניזירונג

ווי איך געזאגט, לויט צו קאָנווייַ ס געזעץ, די אָרגאַניזאַציע פון ​​אַ פירמע ענדערונגען. איך וועט אָנהייבן מיט וואָס פּריווענץ DevOps פון פּענאַטרייטינג אין די פירמע פֿון די אָרגאַנאַזיישאַנאַל פונט פון מיינונג.

די פּראָבלעם פון "ברונען"

דאָס ענגליש וואָרט "סילאָ" איז איבערגעזעצט דאָ אין רוסיש ווי "געזונט". די פונט פון דעם פּראָבלעם איז אַז עס איז קיין וועקסל פון אינפֿאָרמאַציע צווישן טימז. יעדער מאַנשאַפֿט דיגס טיף אין זיין עקספּערטיז, אָן בויען אַ פּראָסט מאַפּע צו נאַוויגירן.

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

DevOps סאַגדזשעסץ צו באַקומען דורך דעם מאָמענט פון דיסאָריענטיישאַן און אַלע דיפּאַרטמאַנץ ארבעטן צוזאַמען צו בויען אַ פּראָסט ינטעראַקשאַן מאַפּע.

צוויי פאקטארן שטערן דעם.

קאָנסעקווענץ פון די פֿירמע פאַרוואַלטונג סיסטעם. עס איז געבויט אין באַזונדער כייעראַרקאַקאַל "וועלז". פֿאַר בייַשפּיל, עס זענען זיכער קפּיס אין קאָמפּאַניעס וואָס שטיצן דעם סיסטעם. אויף די אנדערע האַנט, די מאַרך פון אַ מענטש וואָס איז שווער צו גיין ווייַטער פון די גרענעצן פון זייער עקספּערטיז און נאַוויגירן די גאנצע סיסטעם, באַקומען אין די וועג. עס איז נאָר ומבאַקוועם. ימאַדזשאַן אַז איר זענט אין באַנגקאָק אַעראָפּאָרט - איר וועט נישט געפֿינען דיין וועג געשווינד. DevOps איז אויך שווער צו נאַוויגירן, און אַז ס וואָס מענטשן זאָגן איר דאַרפֿן צו געפֿינען אַ פירער צו באַקומען דאָרט.

אָבער די מערסט וויכטיק זאַך איז אַז די פּראָבלעם פון "וועלז" פֿאַר אַ ינזשעניר וואָס איז ימביוד מיט די גייסט פון DevOps, לייענען Fowler און אַ בינטל פון אנדערע ביכער, איז אויסגעדריקט אין דעם פאַקט אַז "ברונען" לאָזן איר נישט טאָן "קלאָרעוודיק" זאכן. מיר אָפט קומען צוזאַמען נאָך DevOps מאָסקווע, רעדן צו יעדער אנדערער און מענטשן באַקלאָגנ זיך:

- מיר נאָר געוואלט צו קאַטער סי, אָבער עס פארקערט אויס אַז אַדמיניסטראַציע האט נישט דאַרפֿן עס.

דאס כאַפּאַנז דווקא ווייַל CI и קעסיידערדיק עקספּרעס פּראָצעס זענען אויף דער גרענעץ פון פילע יגזאַמאַניישאַנז. פשוט אָן באַקומען די פּראָבלעם פון "וועלז" אויף די אָרגאַנאַזיישאַנאַל מדרגה, איר וועט נישט קענען צו פאָרויס, קיין ענין וואָס איר טאָן און קיין ענין ווי טרויעריק עס איז.

יעדער באַטייליקטער אין דעם פּראָצעס אין די פירמע: באַקענד און פראָנטענד דעוועלאָפּערס, טעסטינג, דבאַ, אָפּעראַציע, נעץ, דיגז אין זייער אייגענע ריכטונג, און קיין איינער האט אַ פּראָסט מאַפּע אַחוץ דער פאַרוואַלטער, וואָס עפעס מאָניטאָרס זיי און מאַנידזשיז זיי מיט די "טיילן" און קאַנגקער" שיטה.

מענטשן קעמפן פֿאַר עטלעכע שטערן אָדער פלאַגס, אַלעמען גראָבן זייער עקספּערטיז.

ווי אַ רעזולטאַט, ווען עס קומט די אַרבעט פון קאַנעקטינג אַלע דעם צוזאַמען און בויען אַ פּראָסט רערנ - ליניע, און עס איז ניט מער דאַרפֿן צו קעמפן פֿאַר שטערן און פלאַגס, די קשיא ערייזאַז - וואָס צו טאָן סייַ ווי סייַ? מיר דארפן עפעס קומען צו א הסכמה, אבער קיינער האט אונז נישט געלערנט ווי אזוי צו טוהן אין שול. מיר האָבן שוין געלערנט זינט שולע: אַכט קלאַס - וואַו! — אין פֿאַרגלײַך מיט דער זיבעטער קלאַס! דאָ איז דאָס זעלבע.

איז עס די זעלבע אין דיין פירמע?

צו קאָנטראָלירן דעם, איר קענען פרעגן זיך די פאלגענדע שאלות.

צי טימז נוצן פּראָסט מכשירים און ביישטייערן צו ענדערונגען צו די פּראָסט מכשירים?

ווי אָפט טאָן טימז ריאָרגאַניזירן - עטלעכע ספּעשאַלאַסץ פון איין מאַנשאַפֿט מאַך צו אן אנדער מאַנשאַפֿט? עס איז אין אַ DevOps סוויווע אַז דאָס איז נאָרמאַל, ווייַל מאל אַ מענטש קען נישט פֿאַרשטיין וואָס אן אנדער עקספּערטיז איז טאן. ער באוועגט זיך צו אן אנדער אָפּטיילונג, אַרבעט דאָרט פֿאַר צוויי וואָכן צו מאַכן פֿאַר זיך אַ מאַפּע פון ​​אָריענטירונג און ינטעראַקשאַן מיט דעם אָפּטיילונג.

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

ווי וויכטיק איז עס פֿאַר מאַנאַדזשערז צו באַקומען פערזענלעכע דערגרייכונגען אָן קאַנסידערינג די דערגרייכונגען פון די פירמע?

אויב איר ענטפֿערן די פראגעס פֿאַר זיך, עס וועט ווערן קלירער צי איר האָבן אַזאַ אַ פּראָבלעם אין דיין פירמע.

ינפראַסטראַקטשער ווי קאָד

נאָך דעם פּראָבלעם איז דורכגעגאנגען, דער ערשטער וויכטיק פיר, אָן וואָס עס איז שווער צו פאָרויס ווייַטער אין DevOps, איז ינפראַסטראַקטשער ווי קאָד.

רובֿ אָפט, ינפראַסטראַקטשער ווי קאָד איז באמערקט ווי גייט:

— לאמיר אלעס אויטאמאטירן אין באש, זיך צודעקן מיט סקריפטן, אז די אדמינס זאלן האבן ווייניגער מאנואלע ארבעט!

אָבער דאָס איז נישט אמת.

ינפראַסטראַקטשער ווי קאָד מיטל אַז איר באַשרייַבן די IT סיסטעם מיט וואָס איר אַרבעט אין די פאָרעם פון קאָד צו קעסיידער פֿאַרשטיין זייַן שטאַט.

צוזאַמען מיט אנדערע טימז, איר מאַכן אַ מאַפּע אין די פאָרעם פון קאָד אַז אַלעמען קענען פֿאַרשטיין און קענען נאַוויגירן און נאַוויגירן. עס איז ניט קיין חילוק אויף וואָס עס איז געטאן - שעף, אַנסיבלע, זאַלץ אָדער ניצן YAML טעקעס אין קובערנעטעס - עס איז קיין חילוק.

אויף דער קאָנפֿערענץ האָט אַ קאָלעגע פֿון 2GIS דערציילט ווי זיי האָבן געמאַכט זייער אייגענע אינערלעכע זאַך פֿאַר Kubernetes, וואָס באשרייבט די סטרוקטור פון יחיד סיסטעמען. צו באַשרייַבן 500 סיסטעמען, זיי דאַרפֿן אַ באַזונדער געצייַג וואָס דזשענערייץ דעם באַשרייַבונג. ווען עס איז די באַשרייַבונג, אַלעמען קענען קאָנטראָלירן מיט יעדער אנדערער, ​​מאָניטאָר ענדערונגען, ווי צו טוישן עס און פֿאַרבעסערן עס, וואָס איז פעלנדיק.

שטימען, יחיד באַש סקריפּס יוזשאַוואַלי טאָן ניט צושטעלן דעם פארשטאנד. אין איינע פון ​​די פירמעס וואו איך האב געארבעט, איז אפילו געווען א נאמען פאר "שרייב נאר" שריפט - ווען מען שרייבט די שריפט, אבער עס איז שוין נישט מעגליך עס צו ליינען. איך מיין אז דאס איז דיר אויך באקאנט.

ינפראַסטראַקטשער ווי קאָד איז קאָד וואָס באשרייבט די קראַנט שטאַט פון די ינפראַסטראַקטשער. פילע פּראָדוקט, ינפראַסטראַקטשער און דינסט טימז אַרבעט צוזאַמען אויף דעם קאָד, און רובֿ ימפּאָרטאַנטלי, זיי אַלע דאַרפֿן צו פֿאַרשטיין ווי די קאָד אַקשלי אַרבעט.

דער קאָד איז מיינטיינד לויט צו בעסטער קאָד פּראַקטיסיז: שלאָס אַנטוויקלונג, קאָד אָפּשאַצונג, XP-פּראָגראַממינג, טעסטינג, ציען ריקוועס, סי פֿאַר קאָד ינפראַסטראַקטשער - אַלע דעם איז פּאַסיק און קענען זיין געוויינט.

קאָד ווערט אַ פּראָסט שפּראַך פֿאַר אַלע ענדזשאַנירז.

טשאַנגינג ינפראַסטראַקטשער אין קאָד טוט נישט נעמען פיל צייט. יאָ, ינפראַסטראַקטשער קאָד קענען אויך האָבן טעכניש כויוו. יוזשאַוואַלי טימז טרעפן עס אַ יאָר און אַ האַלב נאָך זיי סטאַרטעד ימפּלאַמענינג "אינפראַסטרוקטור ווי קאָד" אין די פאָרעם פון אַ בינטל פון סקריפּס אָדער אפילו Ansible, וואָס זיי שרייַבן ווי ספּאַגעטי קאָד, און זיי אויך וואַרפן באַש סקריפּס אין די מישן!

עס ס וויכטיק: אויב איר האָט נישט געפרוווט דעם שטאָפּן נאָך, געדענקען אַז אַנסיבלע איז נישט באַש! לייענען די דאַקיומענטיישאַן קערפאַלי, לערנען וואָס זיי שרייַבן וועגן אים.

ינפראַסטראַקטשער ווי קאָד איז די צעשיידונג פון ינפראַסטראַקטשער קאָד אין באַזונדער לייַערס.

אין אונדזער פירמע, מיר ויסטיילן 3 יקערדיק לייַערס, וואָס זענען זייער קלאָר און פּשוט, אָבער עס קען זיין מער פון זיי. איר קענט קוקן אין דיין ינפראַסטראַקטשער קאָד און זאָגן צי איר האָבן דעם צושטאַנד אָדער נישט. אויב קיין לייַערס זענען כיילייטיד, איר דאַרפֿן צו נעמען עטלעכע מאָל און רעפאַקטאָר אַ ביסל.


באַזע שיכטע - דאָס איז ווי די אַס, באַקאַפּס און אנדערע נידעריק-מדרגה טינגז זענען קאַנפיגיערד, למשל, ווי Kubernetes איז דיפּלויד אויף די יקערדיק מדרגה.

סערוויס מדרגה - דאָס זענען די סערוויסעס וואָס איר צושטעלן צו די דעוועלאָפּער: לאָגינג ווי אַ דינסט, מאָניטאָרינג ווי אַ דינסט, דאַטאַבייס ווי אַ דינסט, באַלאַנסער ווי אַ דינסט, ריי ווי אַ דינסט, קעסיידערדיק עקספּרעס ווי אַ דינסט - אַ בינטל פון סערוויסעס וואָס יחיד טימז קענען צושטעלן צו אַנטוויקלונג. דאָס אַלץ דאַרף זיין דיסקרייבד אין באַזונדער מאַדזשולז אין דיין קאַנפיגיעריישאַן פאַרוואַלטונג סיסטעם.

די שיכטע ווו אַפּלאַקיישאַנז זענען געמאכט און באשרייבט ווי זיי וועלן אַנפאָולד אויף שפּיץ פון די פריערדיקע צוויי לייַערס.

פּרובירן פראגעס

צי דיין פירמע האָבן אַ פּראָסט ינפראַסטראַקטשער ריפּאַזאַטאָרי? זענט איר אָנפירונג טעכניש כויוו אין דיין ינפראַסטראַקטשער? צי איר נוצן אַנטוויקלונג פּראַקטיסיז אין אַן ינפראַסטראַקטשער ריפּאַזאַטאָרי? איז דיין ינפראַסטראַקטשער סלייסט אין לייַערס? איר קענען קאָנטראָלירן די Base-service-APP דיאַגראַמע. ווי שווער איז עס צו מאַכן אַ ענדערונג?

אויב איר האָט יקספּיריאַנסט אַז עס גענומען אַ טאָג און אַ האַלב צו מאַכן ענדערונגען, דאָס מיטל אַז איר האָבן טעכניש כויוו און דאַרפֿן צו אַרבעטן מיט אים. איר נאָר סטאַמבאַלד אויף אַ טעכניש כויוו גראַבליע אין דיין ינפראַסטראַקטשער קאָד. איך געדענק פילע אַזעלכע מעשיות ווען צו טוישן עטלעכע CCTL איר דאַרפֿן צו רירייט האַלב פון די ינפראַסטראַקטשער קאָד, ווייַל שאפן און די פאַרלאַנג צו אָטאַמייט אַלץ געפֿירט צו די פאַקט אַז אַלץ איז קעראָוד אומעטום, אַלע די כאַנדאַלז זענען אַוועקגענומען, און עס איז נייטיק צו רעפאַקטאָר.

קעסיידערדיק עקספּרעס

זאל ס פאַרגלייַכן דעביט מיט קרעדיט. ערשטער קומט אַ באַשרייַבונג פון די ינפראַסטראַקטשער, וואָס קען זיין גאַנץ יקערדיק. איר טאָן ניט האָבן צו באַשרייַבן אַלץ אין דעטאַל, אָבער עטלעכע יקערדיק באַשרייַבונג איז פארלאנגט אַזוי איר קענען אַרבעטן מיט אים. אַנדערש, עס איז נישט קלאָר וואָס צו טאָן מיט קעסיידערדיק עקספּרעס ווייַטער. אַלע די פּראַקטיסיז אַנפאָולד סיימאַלטייניאַסלי ווען איר קומען צו DevOps, אָבער עס סטאַרץ מיט פארשטאנד וואָס איר האָט און ווי צו פירן עס. דאָס איז פּונקט די פיר פון ינפראַסטראַקטשער ווי קאָד.

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

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

קעסיידער דעליווערינג מיטל

קאָד וואָס איז אין די פּראָדוקט ריפּאַזאַטאָרי קענען שטענדיק זיין דאַונלאָודיד צו פּראָדוקציע. ער קען נישט זיין דיפלייטיד, אָבער ער איז שטענדיק גרייט פֿאַר אים. אַקקאָרדינגלי, איר שטענדיק שרייַבן קאָד מיט אַ שווער-צו-דערקלערן געפיל פון עטלעכע דייַגעס אונטער דיין טיילבאָנע. עס אָפט אויס ווען איר ראָולד אויס ינפראַסטראַקטשער קאָד. דאָס געפיל פון עטלעכע דייַגעס זאָל זיין פאָרשטעלן - עס טריגערז מאַרך פּראַסעסאַז וואָס לאָזן איר צו שרייַבן קאָד אַ ביסל אַנדערש. דאָס זאָל זיין רעקאָרדעד אין די כּללים אין דער אַנטוויקלונג.

צו קאַנסיסטאַנטלי צושטעלן, איר דאַרפֿן אַ אַרטאַפאַקט פֿאָרמאַט וואָס לויפט אַריבער אַ ינפראַסטראַקטשער פּלאַטפאָרמע. אויב איר וואַרפן "לעבן וויסט" פון פאַרשידענע פֿאָרמאַטירונגען אויף אַ ינפראַסטראַקטשער פּלאַטפאָרמע, עס ווערט יונאַפייד, עס איז שווער צו טייַנען, און די פּראָבלעם פון טעכניש כויוו ערייזאַז. דער פֿאָרמאַט פון די אַרטאַפאַקט דאַרף זיין אַליינד - דאָס איז אויך אַ קאָלעקטיוו אַרבעט: מיר אַלע דאַרפֿן צו באַקומען צוזאַמען, ראַסאַל אונדזער סייכל און קומען אַרויף מיט דעם פֿאָרמאַט.

די אַרטאַפאַקט איז קאַנטיניואַסלי ימפּרוווד און ענדערונגען צו פּאַסן די פּראָדוקציע סוויווע ווען עס באוועגט דורך די עקספּרעס רערנ - ליניע. ווען אַ אַרטאַפאַקט באוועגט צוזאמען די רערנ - ליניע, עס קעסיידער ינקאַונטערז עטלעכע ומבאַקוועם זאכן פֿאַר אים, וואָס זענען ענלעך צו וואָס די אַרטאַפאַקט וואָס איר שטעלן אין פּראָדוקציע ינקאַונטערז. אויב אין קלאסישע אַנטוויקלונג דאָס איז דורכגעקאָכט דורך אַ סיסטעם אַדמיניסטראַטאָר וואָס טוט די ראָולאַוט, אין די DevOps פּראָצעס דאָס כאַפּאַנז אַלע די צייט: דאָ זיי טעסטעד עס מיט עטלעכע טעסץ, דאָ זיי וואַרפן עס אין אַ Kubernetes קנויל, וואָס איז מער אָדער ווייניקער ענלעך. צו פּראָדוקציע, און פּלוצלינג זיי סטאַרטעד מאַסע טעסטינג.

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

פאַרשידענע דיפּלוימאַנט סטראַטעגיעס. פֿאַר בייַשפּיל, איר נוצן AB טעסטינג אָדער קאַנאַרי דיפּלוימאַנץ צו פּרובירן די קאָד דיפערענטלי אויף פאַרשידענע קלייאַנץ, באַקומען אינפֿאָרמאַציע וועגן ווי די קאָד אַרבעט און פיל פריער ווי ווען עס איז ראָולד אויס צו 100 מיליאָן יוזערז.

"קאָנסיסטענטלי באַפרייַען" קוקט ווי דאָס.

דער עקספּרעס פּראָצעס Dev, CI, Test, PreProd, Prod איז נישט אַ באַזונדער סוויווע, דאָס זענען סטאַגעס אָדער סטיישאַנז מיט פייערפּרוף סאַמז דורך וואָס דיין אַרטאַפאַקט פּאַסיז.

אויב איר האָבן ינפראַסטראַקטשער קאָד וואָס איז דיסקרייבד ווי די באַזע סערוויס אַפּ, דאָס העלפּס פֿאַרגעסט ניט אַלע סקריפּס, און שרייַבן זיי אַראָפּ ווי קאָד פֿאַר דעם אַרטיפאַקט, העכערן אַרטאַפאַקט און טוישן עס ווי איר גיין.

פראגעס פֿאַר זיך דורכקוק

די צייט פון די באַשרייַבונג פון די פֿעיִקייטן צו מעלדונג אין פּראָדוקציע אין 95% פון קאַסעס איז ווייניקער ווי אַ וואָך? טוט די קוואַליטעט פון די אַרטאַפאַקט פֿאַרבעסערן אין יעדער בינע פון ​​די רערנ - ליניע? איז דא א מעשה וואס עס גייט דורך? צי איר נוצן פאַרשידענע דיפּלוימאַנט סטראַטעגיעס?

אויב אַלע די ענטפֿערס זענען יאָ, איר זענט ינקרעדאַבלי קיל! שרייב דיין ענטפֿערס אין די באַמערקונגען - איך וועל זיין צופרידן).

באַמערקונגען

דאס איז די מערסט שווער פיר פון אַלע. אויף דער DevOpsConf זיצונג, אַ קאָלעגע פון ​​Infobip, גערעדט וועגן אים, איז געווען אַ ביסל צעמישט אין זיין ווערטער, ווייַל דאָס איז טאַקע אַ זייער קאָמפּליצירט פיר וועגן דעם פאַקט אַז איר דאַרפֿן צו מאָניטאָר אַלץ!

פֿאַר בייַשפּיל, אַ לאַנג צייַט צוריק, ווען איך געארבעט בייַ קיק און מיר איינגעזען אַז מיר דאַרפֿן צו מאָניטאָר אַלץ. מיר האבן דאס געטון, און מיר האבן יעצט 150 זאכן אין זאביקס, וועלכע ווערן כסדר נאכגעקוקט. ס'איז געווען שרעקליך, דער טעכנישער דירעקטאָר האט פארדרייען זיין פינגער צו זיין טעמפל:

- בחורים, פארוואס ריגדסטו דעם סערווער מיט עפעס אומקלאר?

אבער דאן האט פאסירט אן אינצידענט וואס האט געוויזן אז דאס איז באמת א זייער קיל סטראַטעגיע.

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

מי ר האב ן זי ך געשאקלט , געעפנ ט אונדזע ר טשארט ן אי ן זאביקס , או ן ע ם הא ט זי ך ארויסגעוויז ן א ז מיט ן א האלבע ר װא ך צוריק , הא ט זי ך שטאר ק געענדערט , ד י אויפפירונ ג פו ן ד י פארלאנגע ן אי ן דע ר אפי־דינסט . דערנאָך מיר געזען אַז די אָפטקייַט פון שיקן אַ זיכער טיפּ פון אָנזאָג האט געביטן. שפּעטער מיר געפונען אַז דאָס זענען אַנדרויד קלייאַנץ. מיר האבן געפרעגט:

— בחורים, װאס איז מיט דיר געװען מיט א האלבע װאך צוריק?

אין ענטפער, מיר געהערט אַ טשיקאַווע געשיכטע וועגן ווי זיי האָבן רידיזיינד די וי. עס איז אַנלייקלי אַז ווער עס יז וועט מיד זאָגן אַז זיי טשיינדזשד די הטטפּ ביבליאָטעק. פֿאַר אַנדרויד קלייאַנץ, עס איז ווי טשאַנגינג זייף אין די קלאָזעט - זיי נאָר טאָן ניט געדענקען. ווי אַ רעזולטאַט, נאָך 40 מינוט פון שמועס, מיר געפונען אַז זיי האָבן געביטן די הטטפּ ביבליאָטעק, און די פעליקייַט טיימינגז האָבן געביטן. דאָס האָט געפֿירט צו די פאַרקער נאַטור אויף די אַפּי סערווער טשאַנגינג, וואָס געפֿירט צו אַ סיטואַציע וואָס געפֿירט אַ ראַסע אין די מעקלער, און עס אנגעהויבן צו קראַך.

אָן טיף מאָניטאָרינג עס איז בכלל אוממעגלעך צו עפענען דעם. אויב די ארגאניזאציע האט נאך די פראבלעם פון "ברונען", ווען יעדער ווארפט געלט איינער דעם אנדערן, קען דאס לעבן נאך יארן. איר פשוט ריסטאַרט די סערווער ווייַל עס איז אוממעגלעך צו סאָלווע די פּראָבלעם. ווען איר מאָניטאָר, שפּור, שפּור אַלע די געשעענישן וואָס איר האָט, און נוצן מאָניטאָרינג ווי טעסטינג - שרייַבן קאָד און גלייך אָנווייַזן ווי צו מאָניטאָר עס, אויך אין די פאָרעם פון קאָד (מיר האָבן שוין די ינפראַסטראַקטשער ווי קאָד), אַלץ ווערט קלאָר ווי אויף דער דלאָניע. אפילו אַזאַ קאָמפּלעקס פּראָבלעמס זענען לייכט טראַקט.

קלייַבן אַלע אינפֿאָרמאַציע וועגן וואָס כאַפּאַנז צו די אַרטאַפאַקט אין יעדער בינע פון ​​די עקספּרעס פּראָצעס - נישט אין פּראָדוקציע.

צופֿעליקער די מאָניטאָרינג צו CI, און עטלעכע יקערדיק טינגז וועט שוין זיין קענטיק דאָרט. שפּעטער איר וועט זען זיי אין טעסט, פּרעדפּראָד און מאַסע טעסטינג. קלייַבן אינפֿאָרמאַציע אין אַלע סטאַגעס, ניט בלויז מעטריקס, סטאַטיסטיק, אָבער אויך לאָגס: ווי די אַפּלאַקיישאַן ראָולד אויס, אַנאַמאַליז - קלייַבן אַלץ.

אַנדערש עס וועט זיין שווער צו געפֿינען עס. איך האָב שוין געזאָגט אַז DevOps איז מער קאָמפּליצירט. צו קאָפּע מיט דעם קאַמפּלעקסיטי, איר דאַרפֿן צו האָבן נאָרמאַל אַנאַליטיקס.

פראגעס פֿאַר זיך-קאָנטראָל

איז דיין מאָניטאָרינג און לאָגינג די אַנטוויקלונג געצייַג פֿאַר איר? ווען שרייבן קאָד, טאָן דיין דעוועלאָפּערס, אַרייַנגערעכנט איר, טראַכטן וועגן ווי צו מאָניטאָר עס?

צי איר הערן וועגן פּראָבלעמס פון קאַסטאַמערז? צי איר פֿאַרשטיין דעם קליענט בעסער פֿון מאָניטאָרינג און לאָגינג? צי איר פֿאַרשטיין די סיסטעם בעסער פון מאָניטאָרינג און לאָגינג? צי איר טוישן די סיסטעם פשוט ווייַל איר געזען אַז דער גאַנג אין די סיסטעם איז גראָוינג און איר פֿאַרשטיין אַז אין נאָך 3 וואָכן אַלץ וועט שטאַרבן?

אַמאָל איר האָבן די דריי קאַמפּאָונאַנץ, איר קענען טראַכטן וועגן וואָס מין פון ינפראַסטראַקטשער פּלאַטפאָרמע איר האָבן אין דיין פירמע.

ינפראַסטראַקטשער פּלאַטפאָרמע

די פונט איז נישט אַז עס איז אַ סכום פון פאַרשידענע מכשירים וואָס יעדער פירמע האט.

די פונט פון אַ ינפראַסטראַקטשער פּלאַטפאָרמע איז אַז אַלע טימז נוצן די מכשירים און אַנטוויקלען זיי צוזאַמען.

עס איז קלאָר אַז עס זענען באַזונדער טימז וואָס זענען פאַראַנטוואָרטלעך פֿאַר דער אַנטוויקלונג פון יחיד טיילן פון דער ינפראַסטראַקטשער פּלאַטפאָרמע. אָבער אין דער זעלביקער צייט, יעדער ינזשעניר טראגט פֿאַראַנטוואָרטלעכקייט פֿאַר דער אַנטוויקלונג, פאָרשטעלונג און העכערונג פון די ינפראַסטראַקטשער פּלאַטפאָרמע. אויף אַן ינערלעך מדרגה עס ווערט אַ פּראָסט געצייַג.

אַלע טימז אַנטוויקלען די ינפראַסטראַקטשער פּלאַטפאָרמע און מייַכל עס מיט זאָרג ווי זייער אייגענע IDE. אין דיין IDE איר ינסטאַלירן פאַרשידענע פּלוגינס צו מאַכן אַלץ פייַן און שנעל, און קאַנפיגיער האָטקייס. ווען איר עפֿענען סובלימע, אַטאָם אָדער וויסואַל סטודיאָ קאָוד, קאָד ערראָרס זענען פּאָרינג אין און איר פאַרשטיין אַז עס איז אוממעגלעך צו אַרבעטן אין אַלע, איר מיד פילן טרויעריק און איר לויפן צו פאַרריכטן דיין IDE.

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

די ינפראַסטראַקטשער פּלאַטפאָרמע ינשורז די אַריבערפירן פון די אַרטאַפאַקט פון אַנטוויקלונג צו דער קליענט מיט קעסיידערדיק פֿאַרבעסערונג אין קוואַליטעט. די IP איז פּראָוגראַמד מיט אַ סכום פון מעשיות וואָס פּאַסירן מיט די קאָד אין פּראָדוקציע. איבער די יאָרן פון אַנטוויקלונג, עס זענען פילע פון ​​​​די מעשיות, עטלעכע פון ​​​​זיי זענען יינציק און פאַרבינדן בלויז צו איר - זיי קענען ניט זיין גוגלעד.

אין דעם פונט, די ינפראַסטראַקטשער פּלאַטפאָרמע ווערט דיין קאַמפּעטיטיוו מייַלע, ווייַל עס האט עפּעס געבויט אין עס וואָס איז נישט אין די קאָנקורענט ס געצייַג. די דיפּער דיין IP, די גרעסערע דיין קאַמפּעטיטיוו מייַלע אין טערמינען פון צייט-צו-מאַרק. אנטפלעק ט דא פאַרקויפער שלאָס פּראָבלעם: איר קענען נעמען עמעצער אַנדערש ס פּלאַטפאָרמע, אָבער ניצן עמעצער אַנדערש ס דערפאַרונג, איר וועט נישט פֿאַרשטיין ווי באַטייַטיק עס איז צו איר. יאָ, ניט יעדער פירמע קענען בויען אַ פּלאַטפאָרמע ווי אַמאַזאָן. דאָס איז אַ שווער שורה ווו די דערפאַרונג פון די פירמע איז באַטייַטיק צו זיין שטעלע אין די מאַרק, און איר קענען נישט נוצן אַ פאַרקויפער שלאָס דאָרט. דאָס איז אויך וויכטיק צו טראַכטן וועגן.

סכעמע

דאָס איז אַ יקערדיק דיאַגראַמע פון ​​אַן ינפראַסטראַקטשער פּלאַטפאָרמע וואָס וועט העלפֿן איר שטעלן אַלע די פּראַקטיסיז און פּראַסעסאַז אין אַ DevOps פירמע.

זאל ס קוק אין וואָס עס באשטייט פון.

מיטל אָרקעסטראַטיאָן סיסטעם, וואָס גיט קפּו, זכּרון, דיסק צו אַפּלאַקיישאַנז און אנדערע באַדינונגס. אויף דעם - נידעריק מדרגה באַדינונגען: מאָניטאָרינג, לאָגינג, סי / סי מאָטאָר, אַרטאַפאַקט סטאָרידזש, ינפראַסטראַקטשער ווי סיסטעם קאָד.

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

איר באַקומען אינפֿאָרמאַציע וועגן ווי דיין ווייכווארג אַרבעט פֿאַר דעם קליענט, טוישן עס, צושטעלן דעם קאָד ווידער, באַקומען אינפֿאָרמאַציע - און אַזוי איר קעסיידער אַנטוויקלען ביידע די ינפראַסטראַקטשער פּלאַטפאָרמע און דיין ווייכווארג.

אין די דיאַגראַמע, די עקספּרעס רערנ - ליניע באשטייט פון פילע סטאַגעס. אבער דאָס איז אַ סכעמאַטיש דיאַגראַמע וואָס איז געגעבן ווי אַ בייַשפּיל - ניט דאַרפֿן צו איבערחזרן עס איינער דורך איינער. סטאַגעס ינטעראַקט מיט באַדינונגס ווי אויב זיי זענען סערוויסעס - יעדער ציגל פון דער פּלאַטפאָרמע טראגט זיין אייגענע געשיכטע: ווי רעסורסן זענען אַלאַקייטיד, ווי די אַפּלאַקיישאַן איז לאָנטשט, אַרבעט מיט רעסורסן, איז מאָניטאָרעד און ענדערונגען.

עס איז וויכטיק צו פֿאַרשטיין אַז יעדער טייל פון דער פּלאַטפאָרמע טראגט אַ געשיכטע, און פרעגן זיך וואָס געשיכטע טוט דעם ציגל פירן, אפֿשר עס זאָל זיין ארלנגעווארפן און ריפּלייסט מיט אַ דריט-פּאַרטיי דינסט. פֿאַר בייַשפּיל, איז עס מעגלעך צו ינסטאַלירן Okmeter אַנשטאָט פון אַ ציגל? טאָמער די גייז האָבן שוין דעוועלאָפּעד דעם עקספּערטיז פיל מער ווי מיר האָבן. אָבער אפֿשר נישט - טאָמער מיר האָבן יינציק עקספּערטיז, מיר דאַרפֿן צו ינסטאַלירן פּראָמעטהעוס און אַנטוויקלען עס ווייַטער.

שאַפונג פון די פּלאַטפאָרמע

דאָס איז אַ קאָמפּלעקס קאָמוניקאַציע פּראָצעס. ווען איר האָבן יקערדיק פּראַקטיסיז, איר אָנהייבן קאָמוניקאַציע צווישן פאַרשידענע ענדזשאַנירז און ספּעשאַלאַסץ וואָס אַנטוויקלען רעקווירעמענץ און סטאַנדאַרדס, און קעסיידער טוישן זיי צו פאַרשידענע מכשירים און אַפּראָוטשיז. די קולטור וואָס מיר האָבן אין DevOps איז וויכטיק דאָ.

מיט קולטור איז אַלץ זייער פּשוט - עס ס וועגן מיטאַרבעט און קאָמוניקאַציע, דאָס הייסט, דער פאַרלאַנג צו אַרבעטן אין אַ פּראָסט פעלד מיט יעדער אנדערע, די פאַרלאַנג צו פירן איין ינסטרומענט צוזאַמען. עס איז קיין ראַקעט וויסנשאַפֿט דאָ - אַלץ איז זייער פּשוט, באַנאַל. פֿאַר בייַשפּיל, מיר אַלע לעבן אין די אַרייַנגאַנג און האַלטן עס ריין - אַזאַ אַ מדרגה פון קולטור.

וואס האסטו?

ווידער, שאלות איר קענען פרעגן זיך.

איז די ינפראַסטראַקטשער פּלאַטפאָרמע דעדאַקייטאַד? ווער איז פאַראַנטוואָרטלעך פֿאַר זייַן אַנטוויקלונג? צי איר פֿאַרשטיין די קאַמפּעטיטיוו אַדוואַנטידזשיז פון דיין ינפראַסטראַקטשער פּלאַטפאָרמע?

איר דאַרפֿן צו קעסיידער פרעגן זיך די פראגעס. אויב עפּעס קענען זיין טראַנספערד צו דריט-פּאַרטיי באַדינונגס, עס זאָל זיין טראַנספערד; אויב אַ דריט-פּאַרטיי דינסט הייבט צו פאַרשפּאַרן דיין באַוועגונג, איר דאַרפֿן צו בויען אַ סיסטעם אין זיך.

אַזוי, DevOps ...

... דאָס איז אַ קאָמפּלעקס סיסטעם, עס מוזן האָבן:

• דיגיטאַל פּראָדוקט.
• געשעפט מאַדזשולז וואָס אַנטוויקלען דעם דיגיטאַל פּראָדוקט.
• פּראָדוקט טימז וואָס שרייַבן קאָד.
• קעסיידערדיק עקספּרעס פּראַקטיסיז.
• פּלאַטפאָרמס ווי אַ דינסט.
• ינפראַסטראַקטשער ווי אַ דינסט.
• ינפראַסטראַקטשער ווי קאָד.
• באַזונדער פּראַקטיסיז פֿאַר מיינטיינינג רילייאַבילאַטי, געבויט אין DevOps.
• א באַמערקונגען פיר וואָס באשרייבט עס אַלע.

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

עס וועט זיין איבער אין אַ פּאָר פון וואָכן DevOpsConf 2019. ווי אַ טייל פון RIT ++. קום צו דער זיצונג, ווו איר וועט געפֿינען פילע קיל ריפּאָרץ וועגן קעסיידערדיק עקספּרעס, ינפראַסטראַקטשער ווי קאָד און DevOps טראַנספאָרמאַציע. ספר דיין טיקיץ, לעצטע פּרייַז טערמין איז 20 מאי

מקור: www.habr.com