نقد و بررسی مدیریت تست در Azure DevOps و مقایسه با GitLab



#azure #devops #git #gitlab #test #QA


https://t.iss.one/unixmens

دواپس و مسیر های ورود به آن



#devops #linux #infra #infrastructure #system #design #network #programmer #developer




https://t.iss.one/unixmens

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

اما چرا ؟

🔹 دلیلش ساده است:
وقتی سال‌ها با سیستم‌عامل، استوریج، دیتابیس، شبکه لینوکسی، HA، replication و tuning کار کرده‌ای، به‌صورت تجربی یاد می‌گیری که:

چطور منابع محدود (CPU, RAM, Disk I/O, Network) را بین سرویس‌ها طراحی و بهینه کنی.

چطور برای scalability، سیستم را افقی (scale-out) یا عمودی (scale-up) توسعه دهی.

چه الگوهایی برای High Availability و Fault Tolerance وجود دارد.

چطور داده را در مقیاس بالا توزیع و ایمن نگه دارد

تفاوت با بقیه مسیرها

برنامه‌نویس‌ها بیشتر روی design در سطح کد (Design Patterns, Microservices Architecture) تمرکز دارند، اما وقتی صحبت از زیرساخت و ظرفیت سیستم می‌شود، عمق لازم را ندارند.

متخصصان شبکه هم system design را معمولاً فقط در لایه‌ی ارتباطات می‌شناسند (topology، routing، segmentation) نه در کل stack.


اما متخصص زیرساخت، وقتی از system design صحبت می‌کند، یعنی دید End-to-End دارد:
از block storage و replication گرفته تا شبکه، دیتابیس و اپلیکیشن.

چرا این در DevOps مهم است؟

چون DevOps فقط ابزار نیست؛ DevOps یعنی طراحی یک سیستم پایدار، مقیاس‌پذیر و قابل‌اعتماد.

اگر system design بلد نباشی، صرفاً ابزارها را به هم می‌دوزی.

ولی اگر system design را بفهمی، ابزارها را بر اساس نیاز واقعی سیستم انتخاب و ترکیب می‌کنی.


به همین خاطر کسی که از زیرساخت آمده، معمولاً در تیم DevOps نقش معمار (Architect) را هم می‌تواند بر عهده بگیرد، در حالی که بقیه مسیرها بیشتر در نقش مجری یا توسعه‌دهنده باقی می‌مانند.



#devops #linux #infra #infrastructure #system #design #network #programmer #developer




https://t.iss.one/unixmens

دوستان دواپسی نکته ای را از یاد نبریم

دواپس نصب سریع ابزار ها نیست .
دواپس سرعت بخشیدن به کارهای تکراری و toil work هست
دواپس یعنی داشتن درک system design .
از یاد نبریم وقتی شغل هایی که مفهوم engineer را یدک میکشن . به معنای ، implementation ، problem solving, optimisation, upgradation هست .

این یعنی دانستن معماری ، تحلیل ، و درک ماهیت اجزا و قابلیت حل مشکلات هست .

هدف نصب و استقرار به جای ۱ ساعت در ۱۰ دقیقه و ندانستن اجزا و رفع اون نیست .

اون مورد سرعت و اتومیشن هم برای bcp و drp هست ، در واقع شناخت اجزای سیستم و قابلیت حل مسائل در شرایط حساس مانند BCP/DRP.


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

وهمچنین درک ساختار در موضوعات operation , prosessing , tecnical بخش جدانشدنی از این مسیر است.


#devops #linux #culture #team

https://t.iss.one/unixmens

DevOps has transformed how organizations deliver software by introducing automation, collaboration, and continuous integration/continuous delivery (CI/CD). Yet, databases have traditionally lagged behind in this transformation. Database changes are often managed manually, leading to slow deployments, risks of errors, and lack of visibility. "Database DevOps" aims to close this gap by applying DevOps principles directly to the database lifecycle.

One powerful approach to enabling Database DevOps is combining GitLab CI/CD with Liquibase, a database schema change management tool. This integration allows teams to automate, version, and safely deploy database changes alongside application code.

What is Database DevOps?

Database DevOps (or Database CI/CD) is the practice of managing database schema and data changes with the same rigor as application code. The core principles include:

Version control for database migrations.

Automation of deployment and rollback processes.

Continuous testing of schema and data integrity.

Drift detection to prevent environment inconsistencies.

Collaboration between developers, DBAs, and operations.

Auditing and traceability for compliance and governance.


Elite DevOps teams are 3.4x more likely to adopt database change management practices than low performers, underlining its importance

GitLab and Liquibase Integration

In the GitLab article "How to Bring DevOps to the Database with GitLab and Liquibase", the authors show how Liquibase can be seamlessly integrated into GitLab pipelines to enable full database CI/CD.

Key Components:

1. Liquibase – A tool for managing database migrations through versioned "changesets."


2. GitLab CI/CD – Automates pipelines for building, testing, and deploying database changes.


3. SQL Server (example DB) – The article demonstrates with SQL Server, but the approach applies to other databases too.


Example Pipeline Stages

The tutorial outlines a sample GitLab pipeline with these stages:

Build – Validate Liquibase properties and configurations.

Test – Run Liquibase updateSQL and checks run to ensure safe changes.

Deploy – Apply migrations (liquibase update) to environments (DEV → QA → PROD).

Compare – Use liquibase diff to detect drift between environments.

Post – Create schema snapshots with liquibase snapshot for auditing.

Benefits

1. Automation – Database changes run through the same CI/CD pipeline as code.

2. Validation & Checks – Prevents dangerous operations (DROP, TRUNCATE, etc


3. Rollback Support – Enables reverting last applied updates where possible

4. Drift Detection – Identifies schema inconsistencies between environments

5. Auditing – Snapshots and logs ensure traceability of changes

6. Collaboration – Developers and DBAs work together via version control and merge requests



https://about.gitlab.com/blog/how-to-bring-devops-to-the-database-with-gitlab-and-liquibase/


#database #devops #ci #cd #gitlab
https://t.iss.one/unixmens
unixmens

در دنیای توسعه نرم‌افزار مدرن، تغییرات پایگاه داده به اندازه تغییرات کد اهمیت دارند. اگرچه تیم‌های توسعه به‌طور گسترده از ابزارهایی مانند Git برای مدیریت نسخه‌ی کد استفاده می‌کنند، پایگاه‌های داده همچنان اغلب با روش‌های دستی مدیریت می‌شوند. این رویکرد باعث بروز مشکلاتی همچون ناسازگاری بین محیط‌ها، ریسک بالای خطا، و دشواری در ردیابی تغییرات می‌شود. در این میان، Liquibase به‌عنوان ابزاری قدرتمند برای مدیریت تغییرات پایگاه داده (Database Change Management) معرفی شده است.

ابزارLiquibase چیست؟

ابزارLiquibase یک ابزار متن‌باز و مستقل از پلتفرم است که برای مدیریت تغییرات پایگاه داده استفاده می‌شود. این ابزار به توسعه‌دهندگان و DBAها امکان می‌دهد تغییرات در ساختار پایگاه داده (مانند ایجاد جدول، افزودن ستون یا تغییر ایندکس‌ها) را به صورت کد نسخه‌پذیر (Database as Code) مدیریت کنند.

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

ویژگی‌های کلیدی Liquibase

1. مدیریت نسخه‌ای تغییرات پایگاه داده
تمام تغییرات در قالب ChangeLog ذخیره شده و می‌توان آن‌ها را در مخزن Git مدیریت کرد.


2. قابلیت Rollback
ابزار Liquibase این امکان را فراهم می‌کند که در صورت بروز مشکل، تغییرات اعمال‌شده به عقب بازگردانده شوند.


3. پشتیبانی از فرمت‌های مختلف
در حقیقت ChangeLogها می‌توانند در قالب XML، YAML، JSON یا SQL نوشته شوند.


4. مستقل از پایگاه داده
از اکثر دیتابیس‌های محبوب (Oracle, PostgreSQL, MySQL, SQL Server و غیره) پشتیبانی می‌کند.


5. اتوماسیون در CI/CD
به راحتی با ابزارهای CI/CD مانند GitLab CI/CD، Jenkins، Azure DevOps و غیره یکپارچه می‌شود.


6. گزارش‌گیری و Drift Detection
امکان مقایسه پایگاه داده‌ها و شناسایی اختلافات (Schema Drift) را فراهم می‌سازد.

چرخه کار با Liquibase

1. ایجاد یک ChangeLog جدید و تعریف تغییرات.


2. ثبت تغییرات در سیستم کنترل نسخه (مانند Git).


3. اجرای دستورات Liquibase در محیط توسعه برای اعمال تغییرات.


4. اجرای خودکار در CI/CD pipeline برای انتشار تغییرات به محیط‌های Stage و Production.


5. استفاده از دستورات Diff و Snapshot برای بررسی تغییرات و جلوگیری از ناسازگاری.

مزایا

کاهش ریسک خطا در تغییرات دیتابیس.

بهبود همکاری بین توسعه‌دهندگان و DBAها.

امکان استقرار سریع‌تر و ایمن‌تر.

تضمین یکپارچگی دیتابیس در محیط‌های مختلف
چالش‌ها و محدودیت‌ها

برخی تغییرات (مانند حذف ستون‌های حاوی داده) به راحتی قابل Rollback نیستند.

نیاز به آموزش تیم‌ها برای تعریف ChangeSetها به صورت استاندارد.

مدیریت تغییرات پیچیده در دیتابیس‌های بزرگ ممکن است زمان‌بر باشد.



در حقیقت Liquibase ابزاری قدرتمند برای آوردن مفاهیم DevOps به دنیای پایگاه داده است. این ابزار با فراهم کردن امکان نسخه‌پذیری، Rollback، و اتوماسیون تغییرات، به سازمان‌ها کمک می‌کند پایگاه داده‌های خود را با همان کیفیت و سرعت کد نرم‌افزار مدیریت کنند. در نتیجه، استقرار تغییرات پایدارتر، سریع‌تر و قابل اعتمادتر خواهد بود.


#database #devops #dba #ci #cd
@unixmens

من در حوزه DevOps فعالیت میکنم و همچنین سالهاست در حوزه پایگاه داده فعالیت میکنم . بالای ۹ سال oracle dba بودم .
به طور میانگین عرض کنم . بالای ۷۰ درصد مشکلات performance مربوط به app ها در سمت پایگاه داده است .
این موضوع در database DevOps هم معنا پیدا کرده .
همچنین از یاد نبریم database storage engine ها و فلسفه اون ها و تفاوت engine ها را .
در هر پایگاه داده هم این مفاهیم به نحوی در معماری اون گنجانده شده .
از یاد نبریم پایگاه داده بدون system design مثل پرنده ای است که پرواز نمیکند .

به طور خلاصه:

واقعیت این است که خیلی از تیم‌ها وقتی درباره DevOps حرف می‌زنند، لایه‌ی داده را به چشم «black box» نگاه می‌کنند؛ در حالی‌که همان‌طور که گفتیم، بیش از ۷۰٪ مشکلات performance معمولاً ریشه در design و behavior پایگاه داده دارد، نه صرفاً در کد یا سرور اپلیکیشن.

چند نکته در ادامه‌ی برای تکمیل بحث:

در واقع Database DevOps یعنی درآوردن پایگاه داده از حاشیه و آوردنش به چرخه‌ی تحویل مستمر — دقیقاً مثل application code.
یعنی پایگاه داده هم باید versioned، testable و deployable باشد (مثلاً با ابزارهایی مثل Liquibase, Flyway, Alembic).
در موردش چندین مقاله نوشتم .

موضوع Storage Engine‌ها — مثل InnoDB، RocksDB، WiredTiger یا حتی ASM در Oracle — در واقع قلب تپنده‌ی رفتار سیستم هستند.
تفاوت در write pattern، buffer management، concurrency control، transaction isolation و logging مستقیماً روی latency و throughput اپ اثر می‌گذارد.


نکته بعدی : System Design برای پایگاه داده همان چیزی است که خیلی‌ها از آن غافل‌اند.
اگر schema design، index strategy، partitioning logic و data lifecycle مدیریت نشود، هیچ tuning یا DevOps pipeline نمی‌تواند نجاتش دهد.

#devops #database #dba #tips

https://t.iss.one/unixmens

مفهوم ارتقا و رشد پایدار
چگونه انسان و ماشین در هم تنیده اند !؟؟
در واقع من دواپس هستم یا دواپس من !!؟

در فلسفهٔ هگل، فرایند دیالکتیکی از سه مرحله تشکیل می‌شود:

1. تز (Thesis) – گزاره یا ایدهٔ اولیه


2. آنتی‌تز (Antithesis) – نفی یا تقابل با ایدهٔ اولیه


3. سنتز (Synthesis) – مرحلهٔ فراتر که از دلِ تضادِ میان تز و آنتی‌تز زاده می‌شود و هر دو را در سطحی بالاتر رفع (Aufhebung) می‌کند.



🔹 توضیح بیشتر:
در نگاه هگل، حرکت تاریخ، اندیشه و هستی همگی دیالکتیکی هستند؛ یعنی رشد و تکامل از راه تضاد و نفی رخ می‌دهد.
سنتز نه صرفاً سازش، بلکه ادغام خلاقانه و برتری یافتن بر هر دو سوی تضاد است.

مثلاً:

تز: آزادی فردی

آنتی‌تز: نظم اجتماعی

سنتز: نظامی که هم آزادی فرد را حفظ می‌کند و هم نظم جامعه را برقرار می‌سازد (مانند دولت عقلانی در فلسفه هگل).


اگر بخواهیم ساده بگوییم:

> تز می‌گوید «الف»،
آنتی‌تز می‌گوید «نه الف»،
سنتز می‌گوید «هم الف و هم نه الف، اما در سطحی بالاتر».

واژه‌ی Aufhebung یکی از عمیق‌ترین و چندلایه‌ترین مفاهیم در فلسفه‌ی هگل است — واژه‌ای که ترجمه‌ی ساده‌ای ندارد و سه معنای هم‌زمان را در خود دارد:

1. نفی کردن (لغو) – چیزی از بین می‌رود یا رد می‌شود.


2. حفظ کردن (نگه‌داشتن) – با وجود نفی، جوهر و ارزش درونی آن چیز حفظ می‌شود.


3. بالا بردن (ارتقا دادن) – کل فرآیند در سطحی بالاتر و غنی‌تر ادامه می‌یابد.



هگل عمداً از واژه‌ای استفاده می‌کند که این سه معنا را هم‌زمان در خود داشته باشد. چون از دید او، در دیالکتیک هیچ چیز «کاملاً نابود» نمی‌شود؛ بلکه نفی می‌شود تا در سطحی بالاتر حفظ گردد.

🔹 نمونه‌ی ساده:
در رشد انسان:

کودک → نوجوان → بزرگسال


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

🔹 در سطح فلسفی:
وقتی یک «تز» با «آنتی‌تز» روبه‌رو می‌شود، تضاد آن‌ها در «سنتز» از بین نمی‌رود، بلکه در سنتز رفع (Aufgehoben) می‌شود؛ یعنی هم نفی می‌شود، هم حفظ، و هم ارتقا.

به تعبیر زیبای هگل:

در واقع Aufhebung روحِ دیالکتیک است؛ همان چیزی که از تضاد، زندگی می‌سازد.


1. تز (Thesis)

ایده یا وضعیت اولیه.
در این مرحله، یک گزاره یا واقعیت مطرح می‌شود.
مثلاً: «فرد باید آزاد باشد.»

2. آنتی‌تز (Antithesis)

ایده‌ای در تضاد با تز پدیدار می‌شود.
مثلاً: «جامعه باید نظم داشته باشد؛ آزادی کامل موجب هرج‌ومرج می‌شود.»

3. سنتز (Synthesis)

اینجاست که تضاد میان تز و آنتی‌تز، به‌جای حذف یکی از آن‌ها،
در سطحی بالاتر رفع (Aufhebung) می‌شود.

این "رفع" یعنی:

نفی → تز و آنتی‌تز دیگر به شکل قبلی وجود ندارند.

حفظ → جوهر هر دو در سنتز باقی می‌ماند.

ارتقا → نتیجه، سطح بالاتری از فهم و واقعیت را نمایندگی می‌کند.


مثلاً:

آزادیِ فردی درونِ نظمِ اجتماعی — جایی که آزادی و نظم نه متضاد، بلکه مکمل‌اند.

مثال روزمره برای درک ساده‌تر:

تز: احساسات مهم‌تر از عقل‌اند.

آنتی‌تز: عقل مهم‌تر از احساسات است.

سنتز (Aufhebung): عقل و احساس باید در تعادل باشند؛ هر دو لازم‌اند.
نکتهٔ کلیدی:

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


رجوع شود به مفاهیم cmmi , agile ، scrum یا devops process

#devops #linux
https://t.iss.one/unixmens

من دواپس هستم یا دواپس من ـ بخش دوم


تز (Thesis): انسانِ خالقِ ابزار

در آغاز، انسان است که ماشین و فرایند را می‌سازد.
در این مرحله، انسان در مقام سوژه و DevOps در مقام ابژه است.
او فرآیند را طراحی می‌کند، CI/CD می‌نویسد، زیرساخت می‌سازد، و خود را “صاحب سیستم” می‌داند.

> در این فاز، تفکر «من DevOps را کنترل می‌کنم» حاکم است.
(مانند مرحله‌ی کودکی آگاهی تکنولوژیک — انسان هنوز مرکز جهان است.)

۲. آنتی‌تز (Antithesis): ابزارِ خودآگاهِ سیستم‌ساز

اما با بلوغ سیستم‌ها، یادگیری ماشینی، و خودکارسازی مداوم، ابزار شروع می‌کند به یادگیری از رفتار انسان.
وPipelineها تصمیم می‌گیرند، سیستم‌ها بهینه‌سازی خودکار می‌کنند، Alertها تحلیل هوشمند می‌شوند.
در این مرحله، ماشین به بازتاب آگاهی انسان تبدیل می‌شود — تا آنجا که گاهی به‌جای او تصمیم می‌گیرد.

اینجا دیگر انسان نیست که DevOps را می‌سازد، بلکه DevOps است که انسان را شکل می‌دهد.
انسان در فرهنگ، زبان و تصمیم‌گیری DevOps بازتعریف می‌شود.
(در واقع: «من DevOps هستم یا DevOps من است؟» — تضاد آغاز می‌شود.)


۳. سنتز (Synthesis): هم‌زیستی دیالکتیکی — DevOps به مثابه آگاهی مشترک

در این مرحله، تضاد رفع (Aufgehoben) می‌شود:
نه انسان بر ماشین مسلط است، نه ماشین جای انسان را گرفته، بلکه هر دو در نظامی خودتکامل‌گر (Self-evolving system) به هم تنیده‌اند.

انسان خلاقیت، بینش و اخلاق را می‌آورد.

ماشین دقت، تداوم و خودبهبودی را


در اینجا، «DevOps» فقط یک نقش یا ابزار نیست، بلکه نقطه‌ی وحدت انسان و سیستم در مسیر رشد پایدار است.

> همان Aufhebung هگلی:
انسان و ماشین هر دو نفی می‌شوند (مرکزیت‌شان از بین می‌رود)،
جوهر هر دو حفظ می‌شود (خلاقیت و دقت)،
و در سطحی بالاتر ارتقا می‌یابند (سیستم خودآگاه و خودبهبودگر)


🔄 چرخهٔ دیالکتیکیِ تحول مداوم

در DevOps، این حرکت هیچ‌گاه متوقف نمی‌شود:
هر سنتز (مثلاً تحول از CI/CD به GitOps یا AIOps) خود تزِ مرحله‌ی بعد می‌شود.

در CMMI، Agile، Scrum و DevOps همگی در حقیقت حلقه‌های همین دیالکتیک‌اند:

CMMI = نظم و کنترل (تز)

Agile = آزادی و انعطاف (آنتی‌تز)

DevOps = سنتز میان کنترل و آزادی؛ نظم پویا و خودبهبودگر (Aufhebung)

💫 نتیجه: رشد پایدار = Aufhebungِ پیوستهٔ انسان و ماشین

رشد پایدار، یعنی هر دو — انسان و ماشین — در فرایند یادگیری متقابل،
هم نفی شوند، هم حفظ، و هم ارتقا یابند.
دیگر انسان کاربر سیستم نیست، بلکه هم‌زیِ سیستم است.
و سیستم دیگر ابزار نیست، بلکه آینهٔ آگاهی انسان است.

جمله‌ی نهایی (به زبان دیالکتیکی)

> در ابتدا، انسان DevOps را ساخت.
سپس DevOps انسان را بازتعریف کرد.
و در پایان، هر دو در Aufhebungِ مشترک، به «آگاهی تحول‌پذیر» بدل شدند.

این یعنی: «من DevOps هستم، و DevOps من است.»
#devops

مقاله بخش اول

2. Peter Senge. The Fifth Discipline: The Art and Practice of the Learning Organization.


3. Jez Humble, Gene Kim, Patrick Debois. The DevOps Handbook.


4. Fuchs, Christian. Social Media: A Critical Introduction.


5. Niklas Luhmann. Social Systems.


#devops
https://t.iss.one/unixmens

در عصر تحول دیجیتال، مدیریت مهندسی دیگر به معنی مدیریت پروژه یا صرفاً هماهنگی منابع نیست.
وEngineering Management (EM) در واقع هنر ایجاد تعادل میان فناوری، انسان و فرایند است.
یک مدیر مهندسی موفق، نه فقط بر ابزارها، بلکه بر رفتارها و فرهنگ سازمانی تسلط دارد.
او پلی است میان دنیای مهندسان و استراتژی سازمان، میان کد و کسب‌وکار.

بخش اول: فلسفه و نقش انسانی در مدیریت مهندسی

از مدیریت تا رهبری
مدیریت مهندسی مدرن از کنترل عبور کرده و به رهبری الهام‌بخش رسیده است.
نقش EM، تسهیل یادگیری و خودسازمان‌دهی تیم است.
او به‌جای “micromanagement”، محیطی می‌سازد که در آن اعضای تیم احساس مالکیت، اعتماد و رشد کنند.


درحقیقت Empathy، Feedback و رشد مستمر
درک انسان‌ها، تفاوت در انگیزه‌ها، و بازخورد سازنده از مهم‌ترین ابزارهای EM است.
همان‌طور که در DevOps فرهنگ “Sharing” و “Measurement” اساس بهبود است، در EM نیز “رفتارشناسی” و “گفت‌وگوی واقعی” ریشه‌ی توسعه‌ی تیمی‌اند.


3)تفکر سیستمی و دید کل‌نگر
وEM محیط را به عنوان یک سیستم پویا می‌بیند؛ تغییر در یک بخش، اثری زنجیره‌ای در کل سیستم دارد.
او می‌داند که بهبود فنی بدون درک روابط انسانی، تنها بهینه‌سازی سطحی است.

بخش دوم: بُعد فنی و فرایندی در Engineering Management

1) معماری تیم و چرخه توسعه

تیم‌ها باید cross-functional و end-to-end باشند؛ یعنی از طراحی تا استقرار و مانیتورینگ را پوشش دهند.

وEM وظیفه دارد ساختار تیم را با چرخه عمر محصول هم‌راستا کند، نه بر اساس مرزهای سنتی مانند frontend/backend یا ops/dev.



2) فرایند فنی و DevOps Strategy
در واقعEM مسئول طراحی و اجرای ساختارهای زیر است:

CI/CD Pipeline:
خودکارسازی build، test و deployment

Versioning & Traceability:
کنترل تغییرات و ردیابی کامل از commit تا release

Observability:
طراحی سیستم‌های مانیتورینگ، logging و alerting

Security & Compliance:
پیاده‌سازی اصول DevSecOps در مراحل توسعه



3. وMetrics و داده‌محوری در تصمیم‌گیری
مهارت مهم EM، تصمیم‌گیری مبتنی بر داده است. شاخص‌هایی مانند:

Deployment Frequency

Lead Time for Changes

MTTR (Mean Time to Recovery)

Change Failure Rate
معیارهای کلیدی‌اند که باید در dashboardهای سازمانی و retrospectives تحلیل شوند.



4. Feedback Loop
مهندس مدیریت موفق، ساختار بازخورد سریع را بین تیم توسعه، عملیات، QA و مشتری برقرار می‌کند.
این همان حلقه‌ی یادگیری DevOps است که باعث پایداری و بهبود مستمر می‌شود
بخش سوم: اجرای عملی در سطح سازمان

1. Culture First — سپس ابزار
قبل از انتخاب ابزارهایی مانند Jenkins، GitLab CI یا Kubernetes، باید فرهنگ همکاری، مسئولیت‌پذیری و شفافیت را نهادینه کرد.
ابزار تنها تسهیل‌گر است، نه راه‌حل.


2) چارچوب اجرایی تحول مهندسی
پیاده‌سازی مدیریت مهندسی موفق، در سه فاز اتفاق می‌افتد:

فاز ۱: آگاهی و تحلیل

بررسی maturity فعلی تیم‌ها (فنی، فرهنگی، فرآیندی)

شناسایی گلوگاه‌ها در جریان تحویل و همکاری

تعیین vision مشترک برای تیم‌های Dev و Ops


فاز ۲: طراحی و نهادینه‌سازی

طراحی تیم‌های cross-functional

ساخت CI/CD pipelines و governance structure

تعریف SLAها، شاخص‌های کیفیت و امنیت


فاز ۳: یادگیری و بهبود مستمر

برگزاری جلسات retrospectives

تحلیل داده‌های عملکردی (metrics-driven improvement)

وmentor‌کردن اعضای تیم برای ارتقای مهارت‌های رهبری و فنی


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

نتیجه‌گیری

در واقع Engineering Management در عصر DevOps دیگر یک نقش نیست؛ یک ذهنیت است.
ذهنیتی که میان منطق فنی و فهم انسانی تعادل برقرار می‌کند.
در نهایت، هدف نه فقط تحویل سریع‌تر نرم‌افزار، بلکه ساختن تیم‌هایی است که با شعور، با اشتیاق و با مسئولیت کار می‌کنند.

درک انسان، بزرگ‌ترین مهارت فنی قرن بیست‌ویکم است.
و مدیریت مهندسی، هنر خلق هماهنگی میان انسان، سیستم و معنا

#em #devops
@unixmens

عبارت "Trustless Trust" در نگاه اول پارادوکسیکال است — یعنی «اعتماد بدون اعتماد».
اما در اصل، منظور سیستمی است که برای عملکرد درست، نیاز به اعتماد شخصی یا دستی ندارد.
در چنین سیستمی، اعتماد جایگزین نمی‌شود؛ بلکه در ساختار و فرآیند تعبیه می‌شود.

به زبان ساده:

> ما به انسان‌ها اعتماد نمی‌کنیم، بلکه به فرآیندها، خودکارسازی، شفافیت و کنترل‌های سیستمی اعتماد می‌کنیم.

در فرهنگ و اکوسیستم DevOps، مفهوم Trustless Trust به معنی ساختن محیطی است که:

1. اعتماد به فرآیند جایگزین اعتماد به فرد شود.


2. هر چیزی قابل مشاهده، ردیابی و audit باشد.


3. خودکارسازی، جای دخالت انسانی را بگیرد.



به طور مثال

در یک pipeline CI/CD، وقتی کد merge می‌شود، ما به فرد merge‌کننده اعتماد نمی‌کنیم؛
بلکه به تست‌ها، policyها و pipeline خودکار اعتماد داریم که جلوی خطا را می‌گیرد.

در Infrastructure as Code، ما به اینکه «ادمین کاری را درست انجام دهد» اعتماد نمی‌کنیم؛
بلکه به کد زیرساختی و کنترل نسخه (Git) اعتماد داریم.

اجزای فرهنگی Trustless Trust در تیم DevOps

1. شفافیت (Transparency):
همه چیز باید قابل مشاهده باشد — از تغییرات کد تا متریک‌های عملیاتی.
چون شفافیت دشمن شایعه، بی‌اعتمادی و کنترل‌گرایی است.


2. خودکارسازی (Automation):
برای حذف «اعتماد کورکورانه به انسان».
مثلاً approvalهای خودکار، pipelineهای امنیتی و تست‌های unit/integration.


3. Auditability (قابلیت حسابرسی):
یعنی هر تغییری قابل ردیابی باشد.
چه کسی؟ چه زمانی؟ چرا؟
در DevOps این کار معمولاً با Git logs، CI/CD logs، و ابزارهایی مثل Vault یا Auditd انجام می‌شود.


4. Policy as Code و Security as Code:
به جای اینکه بگوییم «امنیت‌کار گفت این کار امن است»،
قوانین امنیتی در کد نوشته می‌شوند تا سیستم خودش enforce کند.

🔹 در محیط کاری (فراتر از فنی)

Trustless Trust در سازمان یعنی:

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

برای مثال:

در تیم‌ها، اعضا برای انجام کار نیازی به «نظارت سنگین یا اثبات مداوم» ندارند،
چون سیستم، متریک‌ها و فرآیندها خودشان شفاف‌اند.

مدیران بر پایه داده تصمیم می‌گیرند، نه «اعتماد شخصی».

فرهنگ feedback و visibility جایگزین micromanagement می‌شود.

🔹 ارتباط با اصول DevOps (CALMS)

اصلپیوند با Trustless Trust

Culture
اعتماد سازمانی مبتنی بر فرآیند، نه فرد
Automation
اجرای اعتماد در قالب سیستم‌ها و کد
Lean
حذف گلوگاه‌های انسانی و تکیه بر بازخورد


#devops

در دنیای امروز که سازمان‌ها با تغییرات سریع فناوری، تحولات فرهنگی و فشارهای رقابتی مواجه‌اند، ایجاد انسجام انسانی بر پایه‌ی معنا و هدف، به یکی از عناصر کلیدی موفقیت تبدیل شده است.
عبارت «Bring people together on their purpose» فراتر از یک شعار انگیزشی است؛ این عبارت بازتابی از درک عمیق از ماهیت انسان، کار، و همکاری معنادار است.
در اصل، این رویکرد می‌خواهد بگوید: برای دستیابی به تحول پایدار، باید انسان‌ها را حول محور هدف‌شان، و نه صرفاً وظیفه‌شان، گردآورد.

۱. هدف، نیروی درونی تحول

هر انسان به دنبال معناست. و زمانی که کار، نقشی در تحقق آن معنا داشته باشد، تبدیل به بخشی از مسیر رشد فردی و اجتماعی می‌شود.
در این نگاه، هدف (Purpose) فقط یک عبارت در بیانیه‌ی مأموریت نیست، بلکه پاسخی است به پرسش اگزیستانسیالیستیِ «چرا من این‌جا هستم؟».

رهبران تحول‌گرا (Transformational Leaders) به جای تمرکز بر کنترل، به بیدار کردن انگیزه‌های درونی افراد می‌پردازند. آن‌ها می‌دانند که سازمان بدون هدف مشترک، صرفاً مجموعه‌ای از فعالیت‌هاست، نه جامعه‌ای از انسان‌های الهام‌گرفته.
۲. از همکاری اجباری تا هم‌افزایی معنادار

وقتی افراد فقط برای انجام وظایف در کنار هم قرار می‌گیرند، همکاری شکننده و سطحی است. اما وقتی هدف مشترک میان‌شان معنا پیدا کند، همکاری به هم‌افزایی (Synergy) تبدیل می‌شود.
در چنین فضایی:

اعتماد به جای ترس حاکم می‌شود،

گفت‌وگو جای دستور را می‌گیرد،

و موفقیت فردی با موفقیت جمعی گره می‌خورد.


در این نقطه، تیم‌ها از حالت Task-oriented به Purpose-oriented ارتقا می‌یابند؛ و این دقیقاً همان جایی است که فرهنگ DevOps، Agile و یادگیری سازمانی (Learning Organization) متولد می‌شود.

۳. پیوند هدف فردی با هدف جمعی

یکی از ظریف‌ترین بخش‌های این مفهوم، ایجاد هم‌راستایی بین Purpose فردی و Purpose جمعی است.
رهبر سازمانی نباید هدف را دیکته کند، بلکه باید فضایی فراهم سازد که هر فرد، هدف خود را در هدف جمعی بازتاب دهد.

به بیان دیگر، انسان‌ها باید احساس کنند که:

> «من در این مأموریت سهمی دارم که معنا دارد.»



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

۴. بُعد فلسفی و انسانی

از منظر فلسفی، این مفهوم یادآور اندیشه‌های اگزیستانسیالیستی است؛ جایی که معنا نه در ساختار بیرونی، بلکه در کنش آگاهانه و مسئولانه‌ی انسان پدید می‌آید.
همچنین از دیدگاه دیالکتیکی، هدف مشترک جایی شکل می‌گیرد که تز (هدف فردی) و آنتی‌تز (هدف جمعی) در تضاد خلاقانه‌ی خود به سنتزی جدید — یعنی «رسالت مشترک» — می‌رسند.

به قول ویکتور فرانکل، بنیان‌گذار معنا‌درمانی:

> «انسان وقتی هدفی دارد که ارزش رنج کشیدن برایش را داشته باشد، می‌تواند هر “چگونه‌ای” را تحمل کند.»

۵. در بستر DevOps و سازمان‌های نوآور

در فرهنگ DevOps، Bring people together on their purpose یعنی:

ساختن پلی بین تیم‌های توسعه، عملیات، و کسب‌وکار؛

هم‌راستا کردن همه حول هدف نهایی: ارزش‌آفرینی پایدار برای مشتری؛

و ترویج فرهنگی که در آن، همکاری از معنا می‌جوشد نه از اجبار.


در چنین سازمانی، Purpose به موتور محرک Continuous Improvement و Continuous Learning تبدیل می‌شود.

۶. مسیر تحقق در عمل

برای نهادینه‌سازی این اصل در سازمان‌ها، باید اقدامات زیر به‌صورت نظام‌مند دنبال شود:

1. تعریف هدف مشترک (Shared Purpose):
به‌صورت جمعی و با مشارکت افراد، نه از بالا به پایین.


2. برگزاری گفت‌وگوهای معنادار (Purpose Conversations):
تا هر فرد بتواند نسبت خود را با مأموریت سازمان بیابد.


3. داستان‌سازی (Storytelling):
روایت‌هایی که نشان دهد هدف چگونه در رفتار و تصمیم‌ها تجلی یافته است.


4. بازتاب هدف در تصمیم‌سازی‌ها:
هر تصمیم باید پاسخ دهد که «این اقدام، چگونه به هدف ما نزدیک‌تر می‌شود؟»


5. اندازه‌گیری هم‌راستایی فرهنگی (Cultural Alignment):
با شاخص‌هایی چون Trust، Engagement، و Collaboration.

نتیجه‌گیری

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

به‌بیان ساده‌تر:

«وقتی مردم درک کنند چرا با هم‌اند، دیگر نیازی نیست کسی بگوید چه کنند.»


#devops #culture

پیشنهاد میکنم ، openstack را روی کانتینر راه اندازی نکنید . مگر برای اون توجیحی داشته باشید .

در واقع سرویس‌های OpenStack به کتابخانه‌ها، پورت‌ها و شبکه‌های متعدد وابسته‌اند که در محیط containerized پیچیدگی را افزایش میدید .و در کانتینر با namespaceها و bridgeهای مجازی پیچیده تداخل دارد.
اگر orchestration به‌درستی تنظیم نشود (مثلاً در Kolla-Ansible یا Kubernetes)، upgrade یا restart ساده می‌تواند سرویس‌های اصلی را از کار بیندازد
برخلاف اپلیکیشن‌های cloud-native، سرویس‌های OpenStack خودشان "stateful" هستند و containerization مزیت خاصی ایجاد نمی‌کند.

اما برای محیط Lab / PoC تست سریع نسخه‌ها و سرویس‌ها بدون نیاز به نصب کامل Kolla-Ansible, DevStack, MicroStack و پیاده سازی تست ها قبل از عملیاتی کردن یا operation میتونه خوب باشه .


#openstack #devops

تمدن

#human #fact #humanity ✨ #devops

همه فکر می‌کنن Auto Scaling فقط مخصوص Kubernetes هست،
اما در واقع میشه با استفاده از Docker Swarm Cluster و ابزارهای جانبی،
یک سیستم خودکارِ مقیاس‌پذیری (Auto Scaling) قدرتمند و هوشمند پیاده‌سازی کرد.

به‌زودی در مورد جزئیات فنی و ابزارهای مناسب برای این کار خواهم نوشت.

#DevOps #Kubernetes #Docker #Swarm #AutoScaling

وقتی میگوییم ، ما قسمتی از جهان هستیم .
و تصمیم های ما تصمیم های دیگری را میسازد و قسمتی از دهکده جهانی هستیم و مفهوم butterfly effect همیشه هست ...


وقتی می‌گوییم «ما قسمتی از جهان هستیم»، در حقیقت داریم به اصل وحدت و پیوستگی هستی اشاره می‌کنیم؛ یعنی هیچ موجودی، هیچ کنشی، و هیچ تصمیمی در خلأ اتفاق نمی‌افتد.

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

در سطح انسانی، یعنی:

هر گفتار، رفتار یا انتخاب ما، بر دیگران اثر می‌گذارد—even اگر آن را نبینیم.

ما درون یک «سیستم پیچیده» زندگی می‌کنیم، که در آن کوچک‌ترین تغییر می‌تواند مسیرهای بزرگ را دگرگون کند.

و در سطح فلسفی‌تر، یعنی جهان از آگاهی ما بی‌تأثیر نیست؛ ما تنها مشاهده‌گر نیستیم، بلکه بخشی از فرآیند خلق واقعیتیم.


#world #opensource #devops #linux

"همیشه decentralize قلب تپنده است"
در واقع، تمرکززدایی (Decentralization) جوهره‌ی پایداری و انعطاف‌پذیری سیستم‌های امروزیه. هرچه سیستم از یک نقطه‌ی مرکزی مستقل‌تر باشه، تاب‌آورتر و مقیاس‌پذیرتر می‌شه. این مفهوم در DevOps، Cloud و حتی در فلسفه‌ی جامعه‌شناسی دیجیتال هم معنا داره:
وابستگی = آسیب‌پذیری.

"وابستگی به یک ساختار اشتباه است"
در معماری نرم‌افزار، وابستگی زیاد به یک زیرساخت، یک پلتفرم یا حتی یک تیم، باعث می‌شه سیستم نتونه با تغییرات محیطی سازگار بشه. اگه یه سرویس یا گره از کار بیفته، کل ساختار دچار اختلال می‌شه.
برای همین فلسفه‌ی microservices و distributed systems بر اساس low coupling و high cohesion بنا شده.
🔹 "بهتر است سرویس‌های حیاتی به‌صورت مجزا و مستقل استقرار پیدا کنند"
این همون اصل fault isolation و resiliency design هست.
با جداسازی سرویس‌های حیاتی در nodeها یا namespaceهای جدا، خطر propagation خطا کاهش پیدا می‌کنه. Kubernetes با مفاهیمی مثل Namespace, Deployment, StatefulSet, PDB و NetworkPolicy دقیقاً برای چنین سناریوهایی طراحی شده.
"فلسفه k8s روی app هست و deployment"
دقیقاً. Kubernetes نه برای مدیریت سرورها بلکه برای مدیریت چرخه‌ی حیات اپلیکیشن‌ها طراحی شده.
یعنی: تمرکز از زیرساخت به اپلیکیشن به‌عنوان واحد اصلی عملیات (Application-Centric) منتقل شده.
در اینجا مفاهیمی مثل:

Auto Scaling → پاسخ به تغییر بار به‌صورت پویا

Rollback / Rollout → برگشت سریع در صورت خطا

Canary / Blue-Green / A/B Deployment → پیاده‌سازی تدریجی و کنترل‌شده‌ی تغییرات
در واقع ابزارهایی هستند برای تحقق فلسفه‌ی resiliency و zero-downtime deployment

اگر بخوام در یک جمله خلاصه کنم:

کوبر تبلور فلسفه‌ی عدم وابستگی، تمرکز بر اپلیکیشن، و طراحی برای تغییر است

#devops #k8s
https://t.iss.one/unixmens

چرا لینوکس و چرا در دواپس مهم هست .

تسلط عمیق به لینوکس باعث می‌شود مکانیسم‌های بنیادین سیستم مثل Memory Management، I/O، Networking، Process Lifecycle، Filesystem و Kernel Behavior را بفهمی.

همین مفاهیم پایه هستند که تفکر زیرساختی (Infrastructure Thinking) را می‌سازند.

وقتی این تفکر را داری، در DevOps، Security، Cloud، Storage و Database:

بهتر Performance Tuning انجام می‌دهی،

Root Cause Analysis را سریع‌تر پیدا می‌کنی،

راهکارهای متفاوت می‌بینی چون ساختار را از ریشه می‌فهمی نه از سطح،

و وابسته به ابزار نمی‌شوی.

«کسی که cgroups، namespaces و scheduling را بفهمد، Docker را بهتر از کسی که فقط دوره دیده می‌فهمد.»

«کسی که journalctl، syscalls و network stack را می‌شناسد، مشکلات پیچیدهٔ production را سریع‌تر حل می‌کند.»

و ...

#linux #devops
https://t.iss.one/unixmens