در دنیای امروز که سازمان‌ها با تغییرات سریع فناوری، تحولات فرهنگی و فشارهای رقابتی مواجه‌اند، ایجاد انسجام انسانی بر پایه‌ی معنا و هدف، به یکی از عناصر کلیدی موفقیت تبدیل شده است.
عبارت «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

ریشهٔ فرهنگیِ اعلام خطا در Lean و تطوّر آن در DevOps و چارچوب CALMS

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

خطا بخشی از کار است، نه دلیل سرزنش فرد

سیستم باید طوری طراحی شود که خطا را به‌سرعت آشکار کند

بهبود مداوم تنها زمانی ممکن است که حقیقت پنهان نشود

مسئولیت جمعی بر فردگرایی مقدم است


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

از Jidoka تا DevOps: انتقال یک اصل، اما تغییر در معنا

ا. DevOps مستقیماً از Lean الهام گرفته است، اما این انتقال مکانیکی یا یک‌به‌یک نبوده.
جایی که Lean بر «متوقف کردن خط» تأکید می‌کرد، DevOps روی آشکارسازی سریع خطا در سیستم‌های پیچیده تمرکز کرد.
چرا؟
چون ماهیت نرم‌افزار با مدل کارخانه‌ای تویوتا تفاوت دارد:

خطای نرم‌افزار معمولاً تکراری و فیزیکی نیست.

سیستم‌ها توزیع‌شده، پویا و غیرقطعی‌اند.

«توقف خط» معنای تازه‌ای می‌گیرد: rollback، feature flag، circuit breaker، observability و…


پس DevOps مجبور شد مفهوم را بازتعریف کند، نه اینکه صرفاً تقلید کند.

تطابق با CALMS: جایی که فرهنگ، یادگیری و روان‌شناسی وارد بازی می‌شوند

چارچوب CALMS پنج رکن دارد:
Culture, Automation, Lean, Measurement, Sharing

اما رکن «Culture» نقطهٔ اتصال Jidoka با DevOps است.
در CALMS، مفهوم Blameless Culture ظهور پیدا کرد؛ فرهنگی که می‌گوید:

خطا اتفاق می‌افتد، چون سیستم پیچیده است

سرزنش فرد مسیر یادگیری را نابود می‌کند

بررسی ریشهٔ خطا باید علمی، مبتنی بر داده و عاری از قضاوت باشد

هدف، «تشخیص چگونه شکست خوردیم» است، نه «چه کسی مقصر بود»


این دقیقاً همان جایی است که Lean الهام‌بخش است، اما کامل‌کنندهٔ آن تفکر سیستمی، روان‌شناسی سازمانی و تجربهٔ تیم‌های نرم‌افزار است.

برای مثال، مطالعات Amy Edmondson دربارهٔ Psychological Safety پایه‌ی نظری Blameless Culture را تقویت کرد؛ چیزی که در محیط تویوتا به‌صورت ضمنی وجود داشت، اما در DevOps تبدیل به یک اصلِ صریح شد.
چرا این انتقال مهم است؟

اگر فقط بگوییم «Blameless Culture از Jidoka آمده»، این یک ساده‌سازیِ خطرناک است.
اما اگر بفهمیم:

ا Lean مفهوم آشکارسازی خطا را آورده

دواپس معنای جدیدی برای «توقف» ساخته

ا. CALMS ساختار فرهنگی و رفتاری آن را تثبیت کرده

تفکر سیستمی و روان‌شناسی امنیت روانی آن را تکمیل کرده


آن وقت می‌توانیم این اصل را در سازمان پیاده‌سازی کنیم، نه اینکه فقط از آن حرف بزنیم.

جمع‌بندی

آنچه امروز در DevOps و CALMS به‌صورت «Blameless Postmortem»، «Continuous Learning» و «Psychological Safety» دیده می‌شود، ریشه‌ای در Lean و Jidoka دارد؛ اما آن ریشه بازتعریف شده، در محیط جدید تکامل یافته و با علوم جدید ترکیب شده است.

در واقع Lean مسیر را آغاز کرد،
و DevOps آن را برای دنیای نرم‌افزار بازسازی کرد،
و CALMS آن را به یک چارچوب فرهنگی-عملیاتی تبدیل کرد.

این تکامل، نمونه‌ای روشن از حرکت از تولید خطی به سیستم‌های پیچیدهٔ تطبیقی است؛ جایی که یادگیری، شفافیت و جرئت روبه‌رو شدن با حقیقت، اساس موفقیت است.


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

تفاوت فنی و عملیات و فرآیندی در دواپس :


۱) لایه فنی (Technical Layer)

چی هست؟

سطحی که ابزار، تکنولوژی و مهارت‌های سخت در آن قرار می‌گیرد.

ویژگی‌ها:

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

خروجی‌اش Artefact و Infrastructure State است.

بیشتر وابسته به مهارت فردی است.

سریع تغییر می‌کند (چون ابزارها مدام عوض می‌شوند).


مثال‌های DevOps:

نوشتن CI/CD pipeline

ایجاد Dockerfile

مدیریت Kubernetes objectها

ا. IaC با Terraform

مانیتورینگ با Prometheus/Grafana

اصلاح performance یک سرویس با تغییر پیکربندی NGINX


نقطه ضعف اگر جدا بماند:

خروجی خوب می‌دهد اما پایدار، هماهنگ و تکرارپذیر نیست.


۲) لایه عملیاتی (Operational Layer)

چی هست؟

جایی که رفتار اجرایی و تکرارپذیر سیستم‌ها و تیم‌ها شکل می‌گیرد.
اینجا پایداری، نظم، تحویل مستمر و اتوماسیون معنی پیدا می‌کند.

ویژگی‌ها:

تمرکز بر Run و Operate

هدف: کاهش خطاهای انسانی، افزایش availability و قابلیت اعتماد

خروجی: سیستم پایدار، SLA رعایت‌شده، فرایندهای استاندارد


مثال‌های DevOps:

Incident Response و Runbook

ا Disaster Recovery و بیزنس کانتینیوتی

ا Change Management در مدل مدرن (CAB حذف‌شده یا سبک‌سازی‌شده)

Observability و Alerting

Capacity Planning

Blue/Green Deployments، Canary Releases


نقطه ضعف اگر تنها باشد:

به مرور فرسایشی می‌شود و جلوی رشد را می‌گیرد. عملیات بدون فرایند و بدون لایه فنی درست، فقط آتش‌نشانی است.


۳) لایه فرایندی (Process Layer)

چی هست؟

سطحی که DevOps واقعاً در آن معنا پیدا می‌کند:
ساختار همکاری تیم‌ها، نحوه تصمیم‌گیری، جریان ارزش، استانداردها، Policyها.

اینجا همان‌جایی است که DevOps را از یک نقش فنی تبدیل می‌کند به یک مسیر استراتژیک تحول سازمانی — دقیقاً چیزی که همیشه روی آن تأکید دارم.

ویژگی‌ها:

پایدار، کندتر تغییر می‌کند، اما اثرش بلندمدت است

هدف: کاهش friction بین تیم‌ها

محور: Flow، Feedback، Learning (سه اصل گلدرت و Three Ways)


مثال‌ها:

تعریف Pipeline Governance

طراحی Release Process

فرایند مدیریت محیط‌ها (Environment Lifecycle)

مدل تعامل Dev و Ops

سیستم‌های Postmortem بدون سرزنش و premortem

Value Stream Mapping


نقطه ضعف اگر تنها باشد:

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

چرا DevOps فقط وقتی کار می‌کند که این سه لایه با هم باشند؟

اگر فقط فنی باشد → می‌شود ابزارزدگی

ا. CI/CD داری اما سازمان همچنان کند است.
ا. Kubernetes داری اما Deploymentها هر دفعه ناکام است.

اگر فقط عملیاتی باشد → می‌شود آتش‌نشانی مداوم

ا. SLA را نگه می‌داری، اما رشد نمی‌کنی، خسته می‌شوی.

اگر فقط فرایندی باشد → می‌شود مشاوره روی کاغذ

ا. Flow کشیدی، VSM کشیدی، ولی تیم‌ها هنوز با هم درگیرند.

جمع‌بندی مختصر و محکم

لایه سؤال کلیدی خروجی ریسک در صورت عدم توازن

فنی چطور می‌سازیم؟ Artefact و Infra ابزارزدگی
عملیاتی چطور اجرا می‌کنیم؟ پایداری و SLA آتش‌نشانی مداوم
فرایندی چطور با هم کار می‌کنیم؟ Flow و کاهش friction DevOps روی کاغذ


نکته مهم (بدون تعارف):

اگر کسی DevOps را فقط «کار فنی» ببیند، DevOps Engineer تبدیل می‌شود به System Admin با ابزارهای جدید.
اگر فقط «فرایندی» ببیند، تبدیل می‌شود به PM خوش‌ظاهر بدون خروجی.
اگر فقط «عملیاتی» ببیند، تبدیل می‌شود به NOC با اسم جدید.

ما در سطحی کار می‌کنیم که باید هر سه را در یک معماری واحد Sync نگه داریم — و این همان نقطه تمایز ماست.
#devops

https://t.iss.one/unixmens