برای کاربر یک سامانه دولتی، فناوری معمولاً تا زمانی نامرئی است که مشکلی ایجاد نشود. شهروند وارد سامانه میشود، درخواست خود را ثبت میکند و انتظار دارد خدمت مورد نظرش در همان لحظه در دسترس باشد. مدیر نیز انتظار دارد گزارشها، اطلاعات مالی، پروندهها و فرایندهای سازمان بدون وقفه در اختیار او قرار گیرند. اما پشت این تجربه ظاهراً ساده، مجموعهای دائمی از تغییرات جریان دارد: قوانین عوض میشوند، فرایندهای اداری تغییر میکنند، قابلیتهای تازه اضافه میشوند، اشکالات نرمافزاری پیدا میشوند و تهدیدهای امنیتی نیز متوقف نمیمانند.
بنابراین یک سامانه حاکمیتی نمیتواند پس از راهاندازی، «تمامشده» تلقی شود. مسئله اصلی این است که چگونه میتوان چنین سامانهای را مرتب توسعه داد، بدون آن که هر تغییر به قطعی، خطا یا اختلال در خدمت منجر شود.
اینجاست که DevOps اهمیت پیدا میکند. DevOps صرفاً مجموعهای از ابزارهای فنی نیست؛ روشی برای نزدیک کردن توسعه نرمافزار، آزمون، استقرار و عملیات روزمره است تا تغییرات کوچکتر، کنترلشدهتر و سریعتر وارد محیط واقعی شوند.
در حکمرانی دیجیتال، این موضوع مستقیماً به کیفیت خدمت عمومی ارتباط دارد: هرچه وابستگی سازمان به یک سامانه بیشتر شود، کیفیت فرایند توسعه و استقرار آن نیز بخشی از کیفیت حکمرانی خواهد بود.
DevOps دقیقاً چه مسئلهای را حل میکند؟
در مدل سنتی توسعه نرمافزار، تیم توسعه ممکن است چند ماه روی نسخه جدید کار کند و در پایان، مجموعه بزرگی از تغییرات را یکجا تحویل تیم عملیات دهد. هرچه حجم این تغییر بیشتر باشد، شناسایی منشأ خطا نیز دشوارتر میشود.
رویکرد DevOps تلاش میکند این فاصله را کاهش دهد. تغییرات کوچکتر و مکرر منتشر میشوند، آزمونها بخش ثابتی از فرایند توسعه هستند، وضعیت سامانه پس از استقرار پایش میشود و اگر نسخه جدید مشکل ایجاد کند، امکان بازگشت سریعتر به وضعیت پایدار وجود دارد.
به بیان ساده، DevOps میخواهد انتشار نسخه جدید از یک «عملیات پرریسک» به یک فرایند عادی و کنترلشده تبدیل شود.
پشت یک استقرار کمریسک چه اتفاقی میافتد؟
DevOps را نباید به نصب یک نرمافزار یا راهاندازی یک Pipeline تقلیل داد. چند سازوکار باید در کنار یکدیگر قرار گیرند تا نتیجه واقعی حاصل شود.
آزمون خودکار
هر تغییر پیش از ورود به محیط عملیاتی، مجموعهای از آزمونها را پشت سر میگذارد تا مشخص شود قابلیتهای قبلی آسیب ندیدهاند.
چند محیط مجزا
نسخه جدید ابتدا در محیط توسعه و آزمایشی اجرا میشود و پس از اطمینان از عملکرد، به محیط واقعی میرسد.
انتشار تدریجی و کوچک
به جای تجمیع دهها تغییر در یک نسخه بزرگ، تغییرات محدودتر و با فاصله زمانی کوتاهتر منتشر میشوند.
پایش و ثبت رخدادها
بعد از انتشار نیز کار تمام نمیشود. خطاها، سرعت پاسخ، مصرف منابع و وضعیت سرویسها باید دیده شوند.
برنامه بازگشت
اگر تغییر تازه مشکل ایجاد کرد، تیم باید بتواند بدون عملیات پیچیده نسخه قبلی را بازگرداند.
امنیت در چرخه توسعه
آسیبپذیری نباید فقط در پایان پروژه کنترل شود؛ امنیت باید از مرحله توسعه تا استقرار همراه محصول باشد.
اهمیت این اصول برای سامانههایی مانند سماد که روزانه هزاران کاربر دارد با یک سایت شرکتی معمولی یکسان نیست.
در خدمات حاکمیتی، «پایداری» فقط یک شاخص فنی نیست. هر دقیقه اختلال میتواند به توقف یک خدمت عمومی، افزایش مراجعات حضوری و انتقال دوباره هزینه از سامانه به سازمان و شهروند منجر شود.
وقتی میلیونها نفر به سامانههای دولتی وابستهاند
این مسئله در ایران دیگر موضوعی حاشیهای نیست. توسعه دولت الکترونیکی در طی سالهای اخیر باعث شده تعداد زیادی از خدمات عمومی به زیرساختهای دیجیتال وابسته شوند.
طبق آمار اعلامشده در تیر ۱۴۰۵، شمار کاربران پنجره ملی خدمات دولت هوشمند از ۶۹ میلیون نفر عبور کرده است. این مقیاس نشان میدهد پایداری خدمات دولتی دیگر فقط دغدغه واحد فناوری اطلاعات نیست؛ اختلال در یک زیرساخت پرکاربرد میتواند میلیونها کاربر را تحتتأثیر قرار دهد.
گزارش مرکز پژوهشهای مجلس نیز تصویر جالبتری ارائه میکند. در دوره فروردین ۱۴۰۳ تا اردیبهشت ۱۴۰۴ بیش از یک میلیارد تراکنش از مسیر مرکز ملی تبادل اطلاعات ثبت شده که حدود ۲۳.۶ میلیون تراکنش، معادل ۲درصد، به دلیل پاسخگویی ناموفق دستگاه سرویسدهنده موفق نبودهاند. گرچه این آمار بهتنهایی نشان نمیدهد منشأ خطا چه بوده و نباید آن را مستقیماً به ضعف DevOps نسبت داد؛ اما ابعاد مسئله پایداری عملیاتی در دولت دیجیتال را بهخوبی نشان میدهد.
بنابراین مسئله ایران دیگر فقط «ساخت سامانه» نیست. مرحله سختتر اکنون آغاز شده است: اداره پایدار، امن و مستمر این حجم از خدمات دیجیتال.
مشکل رایج؛ پروژه تمام میشود، اما خدمت تازه شروع شده است
یکی از خطاهای مهم در پروژههای نرمافزاری دولتی، نگاه پروژهای به سامانه است. قرارداد اجرا میشود، سامانه تحویل میگردد و پروژه از نظر اداری پایانیافته تلقی میشود؛ در حالی که از دید کاربر، آغاز عمر واقعی خدمت بعد از این نقطه است.
قانون تغییر میکند؛ فرمهای جدید و دادههای بیشتر لازم میشود؛ سازمان دیگری باید به این سامانه متصل شود؛ آسیبپذیری تازهای کشف میشود؛ تعداد کاربران بالاتر میرود؛ یک فرایند قدیمی باید بازطراحی شود.
اگر زیرساخت توسعه و انتشار برای چنین تغییراتی آماده نباشد، دو اتفاق رخ میدهد: یا سامانه بهتدریج از نیازهای واقعی سازمان عقب میافتد، یا هر تغییر جدید به عملیات پرهزینه و پرریسکی تبدیل میشود.
این همان جایی است که DevOps از یک موضوع صرفاً مهندسی به مسئلهای مدیریتی مبدل میشود.
تجربه دولتهای دیجیتال؛ سامانه هیچوقت «تمام» نمیشود
استاندارد رسمی خدمات دیجیتال در اکثر کشورها بر این اصل بنا شده که خدمات دیجیتال تمامشده نیستند و باید در طول عمر خود بر اساس نیاز کاربران، تغییر فناوری و سیاستهای دولت مرتب بهبود پیدا کنند. در همین استاندارد، انتشار مکرر نسخهها و پایش مستمر عملکرد بخشی از الزامات خدمت دیجیتال محسوب میشود.
برای مثال سنگاپور این مسئله را در مقیاس زیرساخت ملی دنبال کرده است. Government Technology Agency این کشور، یک پشته فناوری مشترک برای دولت ایجاد کرده که زیرساخت ابری، APIها، هویت دیجیتال، پرداخت و ابزارهای توسعه را در اختیار دستگاهها قرار میدهد. معماری این بستر از روشهایی مانند Microservices، Containerisation و CI/CD پشتیبانی میکند و به گفته GovTech، استفاده از اجزای مشترک میتواند زمان ارائه خدمات جدید را از ماهها به هفتهها کاهش دهد.
پیام این تجربهها روشن است: دولت دیجیتال فقط به «دیجیتالی بودن خدمت» نیاز ندارد؛ به توان تغییر سریع و امنِ همان خدمت نیز احتیاج دارد.
DevOps در سامانههای حکمرانی چه تفاوتی دارد؟
در یک محصول تجاری، انتشار ناموفق شاید به کاهش فروش یا نارضایتی مشتری منجر شود. در سامانه حاکمیتی، پیامدها میتواند گستردهتر باشد؛ زیرا کاربر گاهی مسیر جایگزینی برای دریافت خدمت ندارد.
برای همین، چند اصل در این حوزه اهمیت بیشتری پیدا میکنند: امکان ثبت کامل تغییرات، کنترل دقیق دسترسی توسعهدهندگان، جداسازی محیط آزمایشی از محیط واقعی، حفاظت از دادهها، تهیه نسخه پشتیبان و داشتن برنامه روشن برای رخدادهای بحرانی.
در واقع سؤال مدیر نباید فقط این باشد که «نسخه جدید چه قابلیتهایی دارد؟» بلکه سؤال مهمتر این است: اگر نسخه جدید مشکل ایجاد کرد، چند دقیقه طول میکشد تا بفهمیم چه اتفاقی افتاده و خدمت را به وضعیت پایدار بازگردانیم؟
این پرسش، کیفیت واقعی عملیات نرمافزاری را بسیار بهتر نشان میدهد.
اندازهگیری؛ معیاری که DevOps را از شعار جدا میکند
یکی از نقاط قوت رویکرد DevOps این است که میتوان عملکرد آن را اندازه گرفت. برای سنجش بلوغ DevOps، چهار شاخص شناختهشده اهمیت ویژهای دارند: زمان رسیدن تغییر از کد به محیط واقعی، دفعات استقرار، درصد تغییرات ناموفق و مدت زمان بازیابی پس از یک استقرار ناموفق.
این شاخصها برای مدیر غیرفنی نیز معنادار هستند.
اگر یک اصلاح فوری چند هفته در صف انتشار باقی بماند، به معنای وجود مشکل است؛ همچنین اگر هر نسخه جدید تعداد زیادی خطا ایجاد کند، و یا اگر هنگام اختلال ساعتها طول بکشد تا خدمترسانی بازگردد.
بنابراین بلوغ DevOps را میتوان به زبان مدیریتی ترجمه کرد: سرعت تغییر، ریسک تغییر و سرعت بازیابی.
سماد، تجربهای منحصر بفرد
سامانه یکپارچه و هوشمند مدیریت امور دهیاریها، برای تغییر رویکرد از مدیریت سنتی به یک سیستم شفاف و منسجم.
سماد؛ توسعه سامانهای که نمیتواند متوقف بماند
سامانه مدیریت امور دهیاریها «سماد» با تعداد زیادی فرایند اداری، مالی و مدیریتی سروکار دارد و توسعه آن نیز با استقرار اولیه پایان پیدا نمیکند. تغییر قوانین و الزامات مالی، نیازهای جدید استانها، بازخورد کاربران و توسعه سیستمهای تازه، همگی ضرورت انتشار نسخههای جدید را ایجاد میکنند.
اهمیت این موضوع زمانی بیشتر میشود که یک سامانه در چند استان و نهایتاً در سطح ملی گسترش پیدا کند. تغییری که روی یک بخش از نرمافزار اِعمال میشود، نباید فرایندهای دیگر یا کاربران استانهای مختلف را دچار اختلال کند. به همین دلیل، هرچه دامنه سماد افزایش پیدا کند، فرایندهای منظم توسعه، آزمون، استقرار، پایش و بازیابی نیز اهمیت بیشتری پیدا میکنند.
در چنین مقیاسی، کیفیت محصول فقط با تعداد قابلیتهای آن سنجیده نمیشود؛ توان توسعه مستمر بدون ایجاد اختلال جدی نیز بخشی از کیفیت سامانه است.
این نگاه با مسیر بلندمدت سماد نیز هماهنگ است: تبدیل شدن از یک نرمافزار اجرایی به زیرساختی پایدار برای مدیریت و حکمرانی روستایی.
در فاصله سالهای ۱۴۰۴ تا ۱۴۰۵، همزمان با اختلالات گسترده اینترنت کشور در پی شرایط جنگی و اِعمال محدودیتهای امنیتی در اتصالات اینترنت کشور، سامانه سماد با وجود توسعه مستمر و انتشار دهها تغییر در بخشهای مختلف، در هیچیک از مراحل بهروزرسانی و بهرهبرداری، بیش از ۶۰ ثانیه از دسترس خارج نشد.
جمعبندی؛ پایداری محصول اتفاقی نیست
سامانههای دولتی هر روز سهم بزرگتری از فرایندهای واقعی جامعه و سازمانها را بر عهده میگیرند. با افزایش این وابستگی، دیگر نمیتوان توسعه نرمافزار و عملیات آن را دو مرحله جداگانه دید.
DevOps پاسخی به همین مسئله است: تغییرات کوچکتر، آزمون منظمتر، استقرار کنترلشده، پایش دائم و بازیابی سریعتر. نتیجه مطلوب نیز صرفاً سرعت بیشتر تیم فنی نیست؛ کاهش ریسک سازمان و استمرار خدمت است.
تجربه ایران نشان میدهد دولت دیجیتال اکنون در مقیاسی فعالیت میکند که میلیونها کاربر و میلیاردها تراکنش به سامانههای مختلف وابستهاند. در چنین محیطی، معماری خوب بدون عملیات خوب کافی نیست.
طبیعتاً برای سامانههایی مانند سماد نیز توسعه ملی تنها به افزودن قابلیتهای تازه وابسته نخواهد بود. پایداری، امنیت، امکان توسعه مستمر و مدیریت تغییر، بخشی از همان زیرساختی هستند که حکمرانی دیجیتال روی آن بنا میشود.
اگر سازمان شما در مسیر توسعه یا نوسازی یک سامانه مدیریتی قرار دارد، ارزیابی معماری، فرایند توسعه و الزامات پایداری باید از همان ابتدای پروژه وارد تصمیمگیری شود؛ نه زمانی که اولین اختلال جدی رخ داده است.
شرکت دانشبنیان تدبیرنگر، توسعهدهنده راهکارهای هوشمند، سامانههای اتوماسیون و خدمات یکپارچه دیجیتال در مسیر تحول و توانمندسازی سازمانی کارآمد.
آدرس
ارومیه – خیابان برق از سمت بلوار شهید بهشتی، کوچه ۳، پلاک ۱۲
ایمیل
hello@tadbirnegar.ir
tadbirnegar.com@gmail.com
