مدیریت هرج و مرج: ایجاد نظم با کمک یک نقشه تکنولوژیکی

تصویر: می Unsplash

سلام به همه! ما مهندسان اتوماسیون این شرکت هستیم فناوری های مثبت و ما از توسعه محصولات شرکت پشتیبانی می کنیم: ما از کل خط لوله مونتاژ از اجرای یک خط کد توسط توسعه دهندگان تا انتشار محصولات نهایی و مجوزها در سرورهای به روز پشتیبانی می کنیم. به طور غیررسمی، ما را مهندس DevOps می نامند. در این مقاله می خواهیم در مورد مراحل تکنولوژیکی فرآیند تولید نرم افزار، نحوه مشاهده آنها و طبقه بندی آنها صحبت کنیم.

از مطالبی که در مورد پیچیدگی هماهنگی توسعه چند محصولی خواهید آموخت، نقشه تکنولوژیکی چیست و چگونه به سازماندهی و تکرار راه حل ها کمک می کند، مراحل و مراحل اصلی فرآیند توسعه شامل چه مواردی است، حوزه های مسئولیت چگونه مشخص می شوند. بین DevOps و تیم های شرکت ما.

درباره Chaos و DevOps

اجازه دهید به اختصار توجه کنیم که مفهوم DevOps شامل ابزارها و خدمات توسعه و همچنین متدولوژی ها و بهترین روش ها برای استفاده از آنها می شود. بیایید جهانی را برجسته کنیم هدف از اجرای ایده‌های DevOps در شرکت ما: این کاهش مداوم در هزینه تولید و نگهداری محصولات از نظر کمی است (ساعت کار یا ساعت ماشین، CPU، RAM، دیسک و غیره). ساده ترین و واضح ترین راه برای کاهش هزینه کلی توسعه در سطح شرکت این است که به حداقل رساندن هزینه انجام وظایف سریال معمولی در تمام مراحل تولید اما این مراحل چیست، چگونه می توان آنها را از روند کلی متمایز کرد، از چه مراحلی تشکیل شده است؟

وقتی یک شرکت در حال توسعه یک محصول است، همه چیز کم و بیش روشن است: معمولاً یک نقشه راه و طرح توسعه کلی وجود دارد. اما وقتی خط تولید گسترش می یابد و محصولات بیشتری وجود دارد چه باید کرد؟ در نگاه اول، آنها فرآیندها و خطوط مونتاژ مشابهی دارند و بازی "یافتن X تفاوت" در لاگ ها و اسکریپت ها آغاز می شود. اگر در حال حاضر بیش از 5 پروژه در حال توسعه فعال باشد و پشتیبانی از چندین نسخه در طی چندین سال توسعه یافته باشد چه؟ آیا می‌خواهیم تا حد امکان از راه‌حل‌های بیشتری در خطوط لوله استفاده کنیم یا آماده‌ایم برای توسعه منحصربه‌فرد هر کدام پول خرج کنیم؟

چگونه بین منحصر به فرد بودن و سریال راه حل ها تعادل پیدا کنیم؟

این سؤالات از سال 2015 بیشتر و بیشتر در برابر ما مطرح شد. تعداد محصولات افزایش یافت و ما سعی کردیم بخش اتوماسیون خود (DevOps) را که خطوط مونتاژ این محصولات را پشتیبانی می کرد، به حداقل برسانیم. در همان زمان، من می خواستم تا حد امکان راه حل های زیادی را بین محصولات تکرار کنم. بالاخره چرا یک کار را در ده محصول به روش های مختلف انجام می دهیم؟

مدیر توسعه: "بچه ها، آیا می توانیم به نوعی ارزیابی کنیم که DevOps برای محصولات چه می کند؟"

ماما نمی دانیم، ما این سوال را نپرسیده ایم، اما چه شاخص هایی باید محاسبه شود؟

مدیر توسعه: "چه کسی می داند! فکر..."

مانند آن فیلم معروف: "من به هتل می روم!" - "اوه... می توانید راه را به من نشان دهید؟" پس از تفکر به این نتیجه رسیدیم که ابتدا باید در مورد وضعیت نهایی محصولات تصمیم گیری کنیم. این اولین هدف ما شد.

بنابراین، چگونه می توانید ده ها محصول را با تیم های نسبتاً بزرگ 10 تا 200 نفره تجزیه و تحلیل کنید و معیارهای قابل اندازه گیری را هنگام تکرار راه حل ها تعیین کنید؟

1:0 به نفع Chaos یا DevOps روی تیغه ها

ما با تلاش برای اعمال نمودارهای IDEF0 و نمودارهای مختلف فرآیند کسب و کار از سری BPwin شروع کردیم. سردرگمی بعد از مربع پنجم مرحله بعدی پروژه بعدی شروع شد و این مربع ها برای هر پروژه را می توان در 50+ مرحله به دم یک پایتون بلند کشید. من غمگین شدم و می خواستم روی ماه زوزه بکشم - اصلاً مناسب نبود.

وظایف تولید معمولی

مدل سازی فرآیندهای تولید یک کار بسیار پیچیده و پر زحمت است: شما باید داده های زیادی را از بخش ها و زنجیره های تولید مختلف جمع آوری، پردازش و تجزیه و تحلیل کنید. شما می توانید در این مورد بیشتر در مقاله بخوانید "مدلسازی فرآیندهای تولید در یک شرکت فناوری اطلاعات'.

هنگامی که ما مدل سازی فرآیند تولید خود را شروع کردیم، هدف خاصی داشتیم - انتقال به هر کارمندی که در توسعه محصولات شرکت ما نقش دارد و به مدیران پروژه:

• چگونه محصولات و اجزای آنها، که از commit یک خط کد شروع می شود، در قالب نصب کننده و به روز رسانی به دست مشتری می رسند،
• چه منابعی در هر مرحله از تولید محصول فراهم می شود،
• چه خدماتی در هر مرحله درگیر است،
• چگونه حوزه های مسئولیت برای هر مرحله مشخص می شود،
• چه قراردادهایی در ورودی و خروجی هر مرحله وجود دارد.

روی عکس کلیک کنید تا در اندازه اصلی باز شود

کار ما در شرکت به چندین حوزه عملکردی تقسیم می شود. بخش زیرساخت درگیر بهینه سازی عملکرد کلیه منابع سخت افزاری بخش و همچنین خودکارسازی استقرار ماشین های مجازی و محیط بر روی آنها است. جهت نظارت بر عملکرد خدمات 24/7 کنترل می کند. ما همچنین نظارت را به عنوان یک سرویس برای توسعه دهندگان ارائه می دهیم. جهت گردش کار ابزارهایی را برای مدیریت فرآیندهای توسعه و آزمایش، تجزیه و تحلیل وضعیت کد و به دست آوردن تجزیه و تحلیل در پروژه ها در اختیار تیم ها قرار می دهد. و در نهایت، جهت webdev انتشار نسخه ها را در سرورهای به روز رسانی GUS و FLUS و همچنین مجوز محصولات با استفاده از سرویس LicenseLab را تضمین می کند. برای پشتیبانی از خط لوله تولید، ما بسیاری از خدمات پشتیبانی مختلف را برای توسعه‌دهندگان راه‌اندازی و نگهداری می‌کنیم (شما می‌توانید به داستان‌هایی درباره برخی از آنها در جلسات قدیمی گوش دهید: Op!DevOps! 2016 и Op!DevOps! 2017). ما همچنین ابزارهای اتوماسیون داخلی، از جمله راه حل های منبع باز.

در طول پنج سال گذشته، کار ما تعداد زیادی عملیات مشابه و معمولی را جمع آوری کرده است و به اصطلاح وظایف معمولی، که راه حل آن به طور کامل یا جزئی خودکار است، برای مجریان مشکل ایجاد نمی کند و نیاز به کار قابل توجهی ندارد. ما همراه با حوزه‌های پیشرو، چنین وظایفی را تجزیه و تحلیل کردیم و توانستیم دسته‌بندی‌های فردی یا کار را شناسایی کنیم مراحل تولید، مراحل به مراحل غیر قابل تقسیم تقسیم می شوند و چندین مرحله جمع می شوند زنجیره فرآیند تولید.

ساده ترین مثال از یک زنجیره فناوری، مراحل مونتاژ، استقرار و آزمایش هر یک از محصولات ما در داخل شرکت است. به عنوان مثال، مرحله ساخت شامل بسیاری از مراحل استاندارد جداگانه است: دانلود منابع از GitLab، آماده سازی وابستگی ها و کتابخانه های شخص ثالث، تست واحد و تجزیه و تحلیل کد استاتیک، اجرای اسکریپت ساخت در GitLab CI، انتشار مصنوعات در یک مخزن در ساخت و تولید یادداشت های انتشار از طریق ابزار داخلی ChangelogBuilder ما.

شما می توانید در مورد وظایف معمول DevOps در مقالات دیگر ما در Habré بخوانید:تجربه شخصی: سیستم یکپارچه سازی مداوم ما چگونه به نظر می رسد"و"اتوماسیون فرآیندهای توسعه: چگونه ایده های DevOps را در Positive Technologies پیاده سازی کردیم'.

بسیاری از زنجیره های تولید معمولی شکل می گیرند فرایند ساخت. رویکرد استاندارد برای توصیف فرآیندها استفاده از مدل های کاربردی IDEF0 است.

نمونه ای از مدل سازی فرآیند CI تولید

ما توجه ویژه ای به توسعه پروژه های استاندارد برای یک سیستم یکپارچه سازی مداوم داشتیم. این امکان دستیابی به یکسان سازی پروژه ها را فراهم کرد و به اصطلاح را برجسته کرد نمودار انتشار بیلدها با تبلیغات.

در اینجا نحوه عملکرد آن آمده است. همه پروژه‌ها معمولی به نظر می‌رسند: آنها شامل پیکربندی مجموعه‌هایی هستند که به مخزن عکس فوری در Artifactory می‌روند، پس از آن روی میزهای آزمایشی مستقر و آزمایش می‌شوند و سپس به مخزن انتشار ارتقا می‌یابند. سرویس Artifactory یک نقطه واحد برای توزیع تمام مصنوعات ساخت بین تیم ها و سایر خدمات است.

اگر طرح انتشار خود را تا حد زیادی ساده و تعمیم دهیم، شامل مراحل زیر می شود:

• ساخت محصول بین پلتفرمی،
• استقرار در میزهای آزمایش،
• راه اندازی تست های عملکردی و دیگر،
• ارتقاء مجموعه های آزمایش شده برای انتشار مخازن در Artifactory،
• انتشار بیلدهای انتشار برای به روز رسانی سرورها،
• تحویل ساخت و به روز رسانی به تولید،
• راه اندازی نصب و به روز رسانی محصول.

اجازه دهید به عنوان مثال، مدل تکنولوژیکی این طرح انتشار معمولی (که از این پس به سادگی مدل نامیده می‌شود) را در قالب یک مدل عملکردی IDEF0 در نظر بگیریم. این منعکس کننده مراحل اصلی فرآیند CI ما است. مدل های IDEF0 به اصطلاح استفاده می کنند نماد ICOM (Input-Control-Output-Mechanism) برای توصیف اینکه در هر مرحله از چه منابعی استفاده می شود، بر اساس قوانین و الزاماتی که کار انجام می شود، خروجی چیست و چه مکانیزم ها، خدمات یا افرادی یک مرحله خاص را اجرا می کنند.

روی عکس کلیک کنید تا در اندازه اصلی باز شود

به عنوان یک قاعده، در مدل های عملکردی، تجزیه و جزئیات شرح فرآیندها آسان تر است. اما با افزایش تعداد عناصر، درک چیزی در مورد آنها دشوارتر می شود. اما در توسعه واقعی مراحل کمکی نیز وجود دارد: نظارت، صدور گواهینامه محصول، اتوماسیون فرآیندهای کاری و موارد دیگر. دقیقاً به دلیل مشکل مقیاس‌بندی است که ما این توصیف را رها کردیم.

تولد امید

در یک کتاب با نقشه‌های قدیمی شوروی مواجه شدیم که فرآیندهای فناوری را توصیف می‌کردند (که اتفاقاً امروزه هنوز در بسیاری از شرکت‌ها و دانشگاه‌های دولتی استفاده می‌شود). صبر کنید، صبر کنید، ما هم یک فرآیند تکنولوژیکی داریم!.. مراحل، نتایج، معیارها، الزامات، شاخص ها و غیره و غیره وجود دارد... چرا سعی نکنیم نقشه های تکنولوژیکی را روی نوار نقاله های محصول خود اعمال کنیم؟ احساسی وجود داشت: "همین است! ما نخ مناسب را پیدا کرده‌ایم، وقت آن است که آن را خوب بکشیم!»

در یک جدول ساده تصمیم گرفتیم محصولات را بر اساس ستون و مراحل و مراحل تکنولوژیک نوار نقاله محصول را بر اساس ردیف ثبت کنیم. مراحل چیزی بزرگ هستند، مانند مرحله مونتاژ یک محصول. و مراحل چیزی کوچکتر و جزئی تر هستند، به عنوان مثال، مرحله دانلود کد منبع در سرور ساخت یا مرحله کامپایل کد.

در محل تلاقی سطرها و ستون های نقشه، وضعیت ها را برای یک مرحله و محصول خاص قرار می دهیم. حالت های بسیاری برای وضعیت ها تعریف شده است:

1. بدون اطلاعات - یا غیر عملی تجزیه و تحلیل تقاضا برای یک مرحله در محصول ضروری است. یا تجزیه و تحلیل قبلا انجام شده است، اما مرحله در حال حاضر مورد نیاز نیست یا توجیه اقتصادی ندارد.
2. به تعویق افتاد - یا در حال حاضر مرتبط نیست. این مرحله در خط لوله مورد نیاز است، اما امسال انرژی برای اجرای آن وجود ندارد.
3. برنامه ریزی شده. این مرحله برای اجرا در سال جاری برنامه ریزی شده است.
4. اجرا شد. مرحله در خط لوله به میزان لازم اجرا می شود.

پر کردن جدول پروژه به پروژه شروع شد. ابتدا مراحل و مراحل یک پروژه را طبقه بندی کردیم و وضعیت آنها را ثبت کردیم. سپس پروژه بعدی را برداشتند، وضعیت ها را در آن ثبت کردند و مراحل و مراحلی که در پروژه های قبلی وجود نداشت را اضافه کردند. در نتیجه ما مراحل و مراحل کل خط لوله تولید خود و وضعیت آنها را در یک پروژه خاص دریافت کردیم. نتیجه چیزی شبیه به یک ماتریس شایستگی برای یک نوار نقاله مواد غذایی است. ما چنین ماتریسی را نقشه فناوری نامیدیم.

با کمک نقشه فناوری، ما به طور ماهوی با تیم‌ها در مورد برنامه‌های کاری سال و اهدافی که می‌خواهیم با هم به آنها دست یابیم به توافق می‌رسیم: چه مراحلی را امسال به پروژه اضافه می‌کنیم و چه مراحلی را برای بعد رها می‌کنیم. همچنین، در حین کار، ممکن است شاهد پیشرفت هایی در مراحلی باشیم که فقط برای یک محصول تکمیل کرده ایم. سپس نقشه خود را گسترش می دهیم و این بهبود را به عنوان یک مرحله یا یک مرحله جدید معرفی می کنیم، سپس برای هر محصول تجزیه و تحلیل انجام می دهیم و امکان تکرار بهبود را پیدا می کنیم.

آنها ممکن است به ما اعتراض کنند: "البته همه اینها خوب است، اما با گذشت زمان تعداد مراحل و مراحل به طرز غیرقابل قبولی زیاد می شود. باید چکار کنم؟

ما توضیحات استاندارد و نسبتاً کاملی از الزامات برای هر مرحله و مرحله معرفی کردیم تا در داخل شرکت برای همه به یک شکل درک شود. با گذشت زمان، همانطور که بهبودها اجرا می شوند، یک مرحله ممکن است در مرحله یا مرحله دیگری جذب شود - سپس آنها فرو می ریزند. در عین حال، همه الزامات و تفاوت های ظریف تکنولوژیکی در الزامات مرحله یا مرحله تعمیم قرار می گیرند.

چگونه می توان تأثیر محلول های تکراری را ارزیابی کرد؟ ما از یک رویکرد بسیار ساده استفاده می‌کنیم: هزینه‌های سرمایه اولیه برای اجرای مرحله جدید را به هزینه‌های کلی محصول سالانه نسبت می‌دهیم و سپس هنگام تکرار، آنها را بین همه تقسیم می‌کنیم.

بخش هایی از توسعه قبلاً به صورت مراحل و مراحل روی نقشه منعکس شده است. ما می توانیم از طریق معرفی اتوماسیون برای مراحل معمولی بر کاهش هزینه های محصول تأثیر بگذاریم. پس از این، تغییرات در ویژگی‌های کیفی، معیارهای کمی و سود دریافتی تیم‌ها (بر حسب ساعت کار یا ساعت ماشین ذخیره شده) را محاسبه می‌کنیم.

نقشه تکنولوژیکی فرآیند تولید

اگر تمام مراحل و مراحل خود را برداریم، آنها را با برچسب ها رمزگذاری کنیم و آنها را در یک زنجیره گسترش دهیم، آنگاه بسیار طولانی و نامفهوم می شود (دقیقاً همان "دم پایتون" که در ابتدای مقاله در مورد آن صحبت کردیم) :

[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]

اینها مراحل مونتاژ محصولات [ساخت]، استقرار آنها برای آزمایش سرورها [استقرار]، آزمایش [آزمایش]، ارتقاء مجموعه‌ها برای انتشار مخازن بر اساس نتایج آزمایش [تبلیغ]، تولید و انتشار مجوزها [مجوز]، انتشار [انتشار] در سرور به‌روزرسانی GUS و تحویل به‌روزرسانی‌های FLUS به سرورها، نصب و به‌روزرسانی اجزای محصول در زیرساخت مشتری با استفاده از مدیریت پیکربندی محصول [نصب]، و همچنین مجموعه‌ای از تله متری [Telemetry] از محصولات نصب شده.

علاوه بر آنها، می توان مراحل جداگانه ای را تشخیص داد: نظارت بر وضعیت زیرساخت [InfMonitoring]، مدیریت نسخه های کد منبع [SourceCodeControl]، آماده سازی محیط مونتاژ [آماده سازی]، مدیریت پروژه [Workflow]، ارائه تیم ها با ابزارهای ارتباطی [ ارتباطات]، صدور گواهینامه محصول [گواهی] و اطمینان از خودکفایی فرآیندهای CI [CISelfSufficiency] (به عنوان مثال، استقلال مجموعه ها از اینترنت). ما حتی ده ها مرحله را در فرآیندهای خود در نظر نخواهیم گرفت، زیرا آنها بسیار خاص هستند.

درک و نگاه کردن به کل فرآیند تولید بسیار ساده تر خواهد بود اگر آن را در فرم تصور کنید نقشه فناوری; این جدولی است که در آن مراحل تک تک تولید و مراحل تجزیه شده مدل در ردیف‌ها و در ستون‌ها شرحی از آنچه در هر مرحله یا مرحله انجام می‌شود ثبت می‌شود. تاکید اصلی بر منابعی است که هر مرحله را فراهم می کند و حدود حوزه های مسئولیت را تعیین می کند.

برای ما نقشه نوعی طبقه بندی کننده است. بخش های تکنولوژیکی بزرگ تولید محصول را منعکس می کند. به لطف آن، تعامل تیم اتوماسیون ما با توسعه دهندگان و برنامه ریزی مشترک اجرای مراحل اتوماسیون و همچنین درک هزینه های نیروی کار و منابع (انسان و سخت افزار) برای این امر آسان تر شده است.

در داخل شرکت ما، نقشه به طور خودکار از یک قالب jinja به عنوان یک فایل HTML معمولی تولید می‌شود و سپس در سرور GitLab Pages آپلود می‌شود. یک اسکرین شات با نمونه ای از یک نقشه کاملا تولید شده قابل مشاهده است по ссылке.

روی عکس کلیک کنید تا در اندازه اصلی باز شود

به طور خلاصه، یک نقشه تکنولوژیکی تصویری کلی از فرآیند تولید است که بلوک‌های طبقه‌بندی شده واضح با عملکرد استاندارد را منعکس می‌کند.

ساختار نقشه تکنولوژیکی ما

نقشه از چند بخش تشکیل شده است:

1. منطقه سرفصل - در اینجا یک توصیف کلی از نقشه ارائه می شود، مفاهیم اساسی معرفی می شوند و منابع اصلی و نتایج فرآیند تولید تعریف می شوند.
2. پنل اطلاعات - در اینجا می توانید نمایش داده ها را برای تک تک محصولات کنترل کنید؛ خلاصه ای از مراحل و مراحل اجرا شده به طور کلی برای همه محصولات ارائه شده است.
3. نقشه فن آوری - شرح جدولی از فرآیند فن آوری. روی نقشه:
   • تمام مراحل، مراحل و کدهای آنها آورده شده است.
   • توضیحات مختصر و کاملی از مراحل داده شده است.
   • منابع ورودی و خدمات مورد استفاده در هر مرحله نشان داده شده است.
   • نتایج هر مرحله و مرحله فردی نشان داده شده است.
   • حوزه مسئولیت برای هر مرحله و مرحله مشخص شده است.
   • منابع فنی تعیین شده است، به عنوان مثال HDD (SSD)، RAM، vCPU، و ساعات کار لازم برای پشتیبانی از کار در این مرحله، هم در حال حاضر - واقعیت، و هم در آینده - برنامه.
   • برای هر محصول مشخص شده است که چه مراحل یا مراحل فناوری برای آن اجرا شده است، برای اجرا برنامه ریزی شده است، نامربوط است یا اجرا نشده است.

تصمیم گیری بر اساس نقشه فناوری

پس از مطالعه نقشه، بسته به نقش کارمند در شرکت (مدیر توسعه، مدیر محصول، توسعه دهنده یا آزمایش کننده) می توانید اقداماتی را انجام دهید:

• درک مراحلی که در یک محصول یا پروژه واقعی وجود ندارد و نیاز به اجرای آنها را ارزیابی کنید.
• در صورتی که چندین بخش در مراحل مختلف کار می کنند، حوزه های مسئولیت را بین چندین بخش مشخص کنید.
• مذاکره در مورد قراردادها برای ورودی ها و خروجی های مراحل.
• مرحله کار خود را در روند کلی توسعه ادغام کنید.
• نیاز به منابع برای پشتیبانی از هر مرحله را با دقت بیشتری ارزیابی کنید.

خلاصه همه موارد فوق

نقشه فناوری همه کاره، قابل توسعه و نگهداری آسان است. توسعه و نگهداری توصیفات فرآیند به این شکل بسیار ساده تر از مدل سختگیرانه آکادمیک IDEF0 است. علاوه بر این، توصیف جدولی ساده تر، آشناتر و ساختار بهتری نسبت به یک مدل کاربردی است.

یک ابزار داخلی ویژه، CrossBuilder، مسئول اجرای فنی مراحل است - یک ابزار لایه بندی بین سیستم های CI، خدمات و زیرساخت. توسعه دهنده نیازی به قطع دوچرخه خود ندارد: در سیستم CI ما کافی است یکی از اسکریپت ها (به اصطلاح وظیفه) ابزار CrossBuilder را اجرا کنیم که با در نظر گرفتن ویژگی های زیرساخت ما آن را به درستی اجرا می کند.

نمایش نتایج: از

معلوم شد که مقاله بسیار طولانی است، اما این امر هنگام توصیف مدل‌سازی فرآیندهای پیچیده اجتناب‌ناپذیر است. در پایان می‌خواهم ایده‌های اصلی خود را به اختصار بیان کنم:

• هدف از معرفی ایده‌های DevOps در شرکت ما کاهش مداوم هزینه‌های تولید و نگهداری محصولات شرکت از نظر کمی (ساعت کار یا ساعت ماشین، vCPU، RAM، دیسک) است.
• یک راه برای کاهش هزینه کلی توسعه، به حداقل رساندن هزینه انجام وظایف سریال استاندارد است: مراحل و مراحل فرآیند تکنولوژیکی.
• یک کار معمولی کاری است که راه حل آن به طور کامل یا تا حدی خودکار است، برای مجریان مشکل ایجاد نمی کند و به هزینه های نیروی کار قابل توجهی نیاز ندارد.
• فرآیند تولید شامل مراحل است، مراحل به مراحل غیرقابل تقسیم تقسیم می شوند که نشان دهنده وظایف معمولی در مقیاس ها و حجم های مختلف است.
• از وظایف استاندارد جدا شده، به زنجیره‌های فناوری پیچیده و مدل‌های چند سطحی فرآیند تولید رسیده‌ایم که می‌توان آن‌ها را با یک مدل کاربردی IDEF0 یا یک نقشه فناوری ساده‌تر توصیف کرد.
• نمودار جریان یک نمایش جدولی از مراحل و مراحل یک فرآیند تولید است. مهمترین چیز: نقشه به شما این امکان را می دهد که کل فرآیند را به طور کامل، در قطعات بزرگ با امکان جزئیات بیشتر مشاهده کنید.
• بر اساس نقشه فناوری، می‌توانید نیاز به اجرای مراحل در یک محصول خاص را ارزیابی کنید، حوزه‌های مسئولیت را مشخص کنید، در مورد قراردادها برای ورودی‌ها و خروجی‌های مراحل توافق کنید و نیاز به منابع را با دقت بیشتری ارزیابی کنید.

در مقالات بعدی با جزئیات بیشتری در مورد اینکه از چه ابزارهای فنی برای پیاده سازی مراحل خاص فناوری بر روی نقشه ما استفاده می شود صحبت خواهیم کرد.

نویسندگان مقاله:

• الکساندر پازدنیکوف - رئیس بخش اتوماسیون (DevOps) در Positive Technologies
• تیمور گیلمولین - قائم مقام رئیس بخش اتوماسیون (DevOps) در Positive Technologies

منبع: www.habr.com