دواپس چیست ؟ | What is DevOps ?

ا DevOps یا دِوآپس، مجموعه ای از روش ها، فرایند ها و ابزارهایی است که با تمرکز بر ارتباطات و همکاری و یکپارچگی بین تیم های توسعه، تضمین کیفیت و عملیات، ارزش های تولید شده را سریع و به صورت مستمر به مشتریان نهایی می رساند. ادغام کلمات اختصاری “Dev” و “Ops” به این موضوع اشاره دارد که توسعه و عملیات به عنوان دو تیم مستقل و کاملا جدای از هم، جای خود را به تیم های چند تخصصی با مهارتها، روش ها و ابزار یکپارچه داده است.
یک تعریف ملموس برای کسب و کار

دواپس اتحاد بین افراد، فرایندها و محصولات برای تحویل مستمر ارزش ها (Continuous Delivery of value) به مشتریان نهایی است. Donovan Brown
دواپس به زبان ساده

در پست دیگری با عنوان “دواپس به زبان ساده چیست ؟” تعریف و توصیف ساده تر و عامیانه تری ارائه شده است.

از جمله الزامات اجرای دواپس می توان به موارد زیر اشاره کرد :

Continuous Integration
Continuous Delivery
Agile Planning
Application Monitoring

چرا دواپس را اجرا کنیم ؟ | Why should implement DevOps ?



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


تاریخچه

در کنفرانس چابک سال ۲۰۰۸، اندرو شفر و پاتریک Debois «زیرساخت چابک» را توصیف کردند. اصطلاح DevOps از طریق یک سری رویداد به نام "devopsdays" در سال ۲۰۰۹ در بلژیک رایج شد. پس از آن کنفرانس‌هایی با نام devopsdays در بسیاری از کشورها در سراسر جهان برگزار شده‌است.#devops @unixmes

چرا ansible ?
https://www.slideshare.net/yasharesmaildokht/ansible-why
#ansible #yashar_esmaildokht @unixmens @automation

مفهوم و ساختار Ansible چیست ؟
چنانچه شما بعنوان یک Linux System Administratior در دیتا سنتری کار کنید میدانید که مدیریت و راهبری تعداد زیاد server کار آسانی نیست مثلا اگر قرار باشد تعداد ۵ تا server را بروز رسانی کنید شاید کار زیاد زمان بری نباشد اما اگر لازم باشد تعداد ۱۰۰ یا ۲۰۰ تا بیشتر را پشتیبانی و بروز رسانی کنید کاری بسیار پر استرس و زمان بر خواهد بود .
در سالهای گذشته بیشتر System Administrator ها از قابلیت نوشت script به منظور راهبری و پشتیبانی server های خود استفاده میکردند که نیاز به دانش عمیق در برنامه نویسی با زبان script داشت و مستلزم وقت برای نوشتن script های صحیح و دقیق و کارا بود . فرض کنید میخواهید کلیه server های خود را update کنید و یا می خواهید backup بگیرید , چنانچه بخواهید بر روی هر server جداگانه این کار را انجام دهید مسلما کاری وقت گیر است که در این زمانه وقت و زمان بسیار در سیستم های آنلاین و برخط مهم است و اینکه server و service شما بالا و برخط باشد و در همان شرایط بتوانید عملیات لازم را روی آن انجام دهید مسئله ای ارزشمند است .
در واقع Ansible یک برنامه opensource برای متمرکز کردن کارهای دیتاسنترها روی server های می باشد . بوسیله Ansible قادر خواهید بود که بسیاری از وظایف ادمین را بصورت خودکار راه اندازی و تعریف کنید تا در زمان مناسب بصورت remote یا از راه دور روی ماشین های شما اجرا گردد. ساختار Ansible بگونه ای طراحی شده است که شما را قادر خواهد ساخت بدون shutdown کردن سیستم به عملیات مختلف روی ماشین های خود ادامه دهید .
مثلا Ansible میتواند عملیاتی مثل update ماشین های مختلف را بصورت Zero Downtime انجام دهد . در ضمن system admin نیازی به نوشتن script های بهینه شده نداشته و میتواند از زبانهای high-level در ansible براحتی استفاده نماید . در Ansible می توانید وظایف را بصورت گروه های مختلف مثلا گروه های مرتبط با host یا نوع آنها و ساختار معماری آنها تعریف نمایید . مفهومی بنام paly در Ansible داریم که مجموع از وظایف مرتبط با یک گروه از host ها را برعهده دارد و فایلی که یک یا بیش از یکی از این palys ها را شامل باشد palybook نامیده می شود . معماری Ansible بصورت agentless است . هر زمانی که Ansible کاری را اجرا کند و فرمانی صادر
کند این کار به ماشین های راه دور منتقل می شود . از آنجاییکه Ansible تعداد زیادی بیش از صد ماژول در core خود دارد لذا کار system administrator ها را خیلی راحت می کند .
در واقع Ansible اولین بار توسط Michael DeHaam طراحی و تولید شد ، شخصی که بوجود آورنده برنامه Collber provisioning بود. از آنجاییکه Ansible بسیار ساده است لذا بسیاری از system admin ها از آن استفاده میکنند . همچنین Developer ها یا توسعه دهندگان برنامه ها نیز می توانند براحتی از Ansible استفاده نمایند زیرا بر پایه زبان Python نوشته شده است . Ansible توسط ابزارهای DevOps مثل Vagrant و Jenkins پشتیبانی می شود. در این بین کارهای زیادی هم وجود دارد که ansible قادر به انجام آنها نیست . مثلا Ansible نمیتواند تغیراتی که توسط کابران در سیستم انجام میگردد را audit یا رسد کند . مثلا اینکه این فایل را چه کسی تغییر داده است .
لیست زیر نمونه ای از کارهایی که توسط Ansible قابل انجام نمی باشد آمده است :
در واقع Ansible می تواند package های مورد نیاز در زمان نصب را اضافه کند، اما قادر به نصب اولیه در حالت minimal روی سیستم نیست . هر سیستمی را میتوان بصورت Minimal راه اندازی کرده و سپس توسط Kickstart یا ابزارهای مشابه یک image از آن تهیه نمود، سپس با Ansible برای پیکربندی های دیگر استفاده کرد .
با اینکه Ansible قادر است پیکربندی مربوط به فایروال را تنظیم نماید اما بر آن نظارتی ندارد . Ansible نمی تواند تغییرات روی فایل های داخل سسیتم را پیگیری کند که آیا این تغییرات توسط کاربر انجام شده یا توسط process . غالبا بهتر است که این گونه تغییرات بهتر است با ابزارهای دیگر مخصوص version control یا ابزارهای audit خود سیستم عامل لینوکس انجام پذیرد.
#ansible #sys_admin #devpos @unixmens

با #jenkins آشنا شویم

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

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

همین روند باعث شد تا روشی جدید برای برنامه نویسی به نام test driven development یا به اختصار TDD ابداع شود. در این روش یک سیکل دائمی وجود دارد که منجر به کاهش جشمگیر میزان باگ ها خواهد شد.

در شکل بالا روند کلی این روش نشان داده شده است. این روش به این صورت است که برنامه نویس باید دو توع کد را موازی با هم پیش ببرد یکی کد اصلی و دیگری کد تست نام دارد. کد تست کد اصلی را تست می کند و کد اصلی خود برنامه اصلی است. روند کار در TDD به این صورت است که ابتدا سعی می کنیم تستی بینویسیم که fail شود. سپس سعی می کنیم تا کد اصلی خود را طوری تغییر دهیم که آن تست pass شود بعد از این کار به تمیز کردن کدهایی که زدیم می پردازیم (مثلا انتخاب نام های بهتر برای متغیرها و کم کردن حجم توابعی که نوشتیم برای خواناتر شدن کد) بعد از این کار این روند را تا ابد تکرار می کنیم. اگر بخواهیم نمودار بالا را ساده تر نشان دهیم می توانیم آن را به سه قسمت Red و Green و Refactor تقسیم کنیم :

د RED : در این حالت هدف نوشتن تستی است که fail شود. شاید پیش خودتان بپرسید چرا باید همچین کاری کرد ؟ جواب این سوال در اینجاست که شما fail شدن تست خود را با چشمان خود می بینید و به این ترتیب به تستی که نوشتید اطمینان پیدا می کنید وقتی در ادامه راه توانستید pass شدن آن را هم ببینید آن وقت هم test شدن و هم pass شدن آن را دیده اید و مطمئن می شوید که این تست درست کار می کند این نکته خیلی مهمی است
د GREEN : برای تستی که در مرحله قبل fail شده کد اصلی ای مینویسید که تست fail شده را pass کند به این ترتیب شما به تست خود اعتماد می کنید چون هم fail شدن و هم pass شدن اش را دیده اید
د REFACTOR : در این مرحله کدهایی که در دو مرحله قبل زده اید را از لحاظ خوانایی بهتر میکنید مثلا کارهایی از قبیل کم کردن تعداد خطوط توابع یا بهینه کردن پارامترهای ورودی آنها

به این ترتیب درواقع ما کد اصلی را مانند قطعات پارل کنار هم قرار می دهیم. هر کدام از این قطعات تست شده اند و احتمال وقوع باگ را در ادامه کار کاهش می دهند. شاید در ابتدا اینگونه به نظر برسد که نوشتن تست برای کد سرعت توسعه را کاهش می دهد شاید در ابتدای کار این حرف درست باشد اما هر چقدر که کار جلوتر می رود دیگر مانند قبل در باتلاقی که توصیف کردم فرو نمی روید و با سرعتی تقریبا ثابت به کار ادامه می دهید. چیزی که در این روش توسعه به شدت محسوس است کاهش میزان debug کردن در حین کار است.
نقش jenkins در این داستان کجاست ؟

حال که نقش تست نرم افزار را درک کردید به سراغ یکی از ابزارهای معروف برای continuous integration به نام jenkins می رویم. این برنامه برای کار تیمی روی یک پروژه درست شده است و بطور اتوماتیک خودش با یک اتفاق خاص (مثلا هر ۲۰ دقیقه یکبار یا با هر بار push کردن کد) تست هایی که برایش به عنوان یک کار (job) تعریف کردیم را اجرا کند و بلافاصله نتیجه را نشان میدهد اگر تست ها fail شدند تمام اطلاعات ذخیره شده و معلوم میشود که با کدام commit بوده که تست fail شده و مشکل را میتوان سریعتر حل کرد مثلا مدیر پروژه میتواند این موضوع را سریعا دیده و اطلاع دهد تا مشکل قبل از بزرگتر شدن حل شود.
نصب jenkins

برای نصب jenkins می توانید به آدرس jenkins.io رفته و متناسب با سیستم عامل خود installer موردنظر خود را دانلود و نصب کنید. همچنین اگر java runtime برروی سیستم شما نصب است می توانید فایل نصب war. را دانلود کنید و با دستور زیر آنرا اجرا کنید:

java -jar <name of file>.war

در دستور بالا به جای <name of the file> نام فایلی را که دانلود کرده اید قرار دهید. (مثلا jenkins.war) بعد از اجرای این دستور در log هایی که در اجرای دستور می آیند شماره پورتی که سرور روی آن اجرا می شوند نمایش داده میشود (معمولا این عدد ۸۰۸۰ است) بعد از اینکه سرور آماده برای کار شد میتوانید در مرورگر ip و port ای که دارید را وارد کنید (اگر local هستید این آدرس localhost:port و اگر برروی سرور این عملیات را انجام دادید server_ip:port را وارد کنید.) پس از انجام مراحل نصب باید چیزی شبیه به تصویر زیر ببینید

این وب اپلیکیشن قسمت های مختلفی دارد مثلا بخش people در منوی سمت چپ افرادی که در سیستم حضور دارند و پروژه های مرتبط با آنها را نمایش می دهد. بخش دیگر new item نام دارد که یکی از اصلی ترین بخش های این نرم افزار است. این بخش برای ایجاد job جدید درست شده. job ها معمولا همان کارهایی هستند که قرار است برای تست کدهای اصلی مان انجام دهیم. مثلا یک job میتواند این باشد که به ازای هر بار push به سرور یک سری تست برروی کدها انجام شود تا اگر تستی fail شد سریعا مشخص شود و سریعا برطرف شود یا حتی میتوان اگر تستی fail شد اجازه push به کاربر داده نشود تا مجبور شود تست ها را pass کند. البته نتیجه این کار را زمانی میتوان مشاهده کرد که تست ها کامل و خوب نوشته شده باشند اگر تست ها ناقص باشند باز هم احتمال وقوع باتلاقی که در ابتدای بحث کردیم وجود دارد !
یک مثال ساده از continuous integration با استفاده از jenkins

برای این که با طرز کار jenkins بهتر آشنا شوید با یک مثال ساده از یک پروژه django بحث را ادامه می دهیم. django یک فریمورک برای ساخت وب سایت است که با زبان برنامه نویسی پایتون (python) نوشته شده است. معمولا وقتی حرف از تست نرم افزار به میان می آید اکثر اوقات منظور unit testing است. به زبان ساده Unit test یعنی تست کردن جزء به جزء سیستم بطور مجزا مثلا یعنی ابنکه به توابع سیستم ورودی های مختلف بدهیم و چک کنیم آیا خروجی های آن با چیزی که انتظار داریم یکسان است یا خیر. در django هم میتوانیم از Unit test ای که خود فریمورک در اختیار ما قرار داده استفاده کنیم تا برنامه خود را تست کنیم. در این مثال میخواهیم کاری کنیم تا بعد از هر بار تغییر در کد هنگام push یکبار تست هایی که برای وب اپلیکیشن نوشتیم اجرا شود و نتیجه را به ما نشان دهد.دقت کنید که مراحل برای تقریبا تمام پروژه های دیگر با هرزبان برنامه نویسی و فریمورکی قابل اجراست ما فقط برای اینکه نتیجه را ملموس تر نشان دهیم با یک پروژه ساده شروع کردیم. مراحل زیر را دنبال کنید:

ابتدا در ضحه اصلی بر روی new item کلیک کنید.
سپس یک نام برای item‌ جدید انتخاب کرده و گزینه free style project را انتخاب کنید و برروی ok کلیک کنید.
در صفحه جدیدی که ایجاد میشود در قسمت Source Code Management گزینه git را انتخاب کنید و تنظیمات مربوط به repository خود را که میخواهید با هر بار push تغییراتش را چک کنید وارد کنید
در قسمت build همین تنظیمات general کدی را که میخواهید به ازای هر بار Push شدن اجرا شود وارد کنید (در django برای اجرای unit test ها باید دستور python manage.py test را اجرا کرد که میتوان در همین قسمت وارد کرد)

پس از ذخیره کردن تنظیمات با هر بار تغییر در کدهای اصلی و push کردن به سرور jenkins کدهای جدید را تست میکند و نتیجه را اعلام میکند که میتوان در صفحه مربوط به item ایجاد شده آن را مشاهده کرد.

ادغام مداوم مهمترین بخش DevOps است که برای ادغام مراحل مختلف DevOps استفاده می شود. Jenkins معروفترین ابزار ادغام مداوم است. Jenkins بر روی سروری نصب می شود که ساخت مرکزی در آن انجام خواهد شد.

گاهی در کنار Jenkins از Hudson نیز نام برده می شود. Hudson ابزار ادغام مداوم مبتنی بر جاوا و متن باز است که توسط Sun Microsystems توسعه یافته و سپس به دست Oracle افتاده است. Oracle پس از مالکیت Sun، یک انشعاب از کد منبع Hudson به نام Jenkins معرفی شد.

ادغام مداوم چیست؟

در واقع Continuous Integration یا ادغام مداوم یک عمل توسعه است که نیاز به توسعه دهندگان دارد تا کد را در یک مخزن مشترک در فواصل منظم ادغام و یکپارچه کنند. این مفهوم به این معنی بود که مشکل پیدا کردن وقایع بعدی در چرخه عمر ساخت را حل کند. یکپارچه سازی مداوم به توسعه دهندگان نیاز دارد تا ساخت های مکرر داشته باشند. هر زمان که یک کد رخ می دهد، یک ساختار باید فعال شود.

ابزار Jenkins چیست؟

در واقع Jenkins یک ابزار نرم افزاری ادغام مداوم است که در زبان برنامه نویسی جاوا برای تست و گزارش دهی بر روی تغییرات جداگانه در یک code base بزرگتر در زمان واقعی نوشته شده است.

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

در واقع Jenkins برای ساخت و تست پروژه های نرم افزاری استفاده می شود و کار را برای توسعه دهندگان جهت ادغام و یکپارچه سازی مداوم تغییرات در پروژه و ایجاد ساخت برای کاربران را آسان می سازد.

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

در واقع Jenkins ادغام مداوم را به کمک پلاگین ها انجام می دهد. اگر می خواهید یک ابزار خاص را ادغام کنید، باید پلاگین هایی برای این ابزار نصب کنید. به عنوان مثال: Git، Maven 2 project، Amazon EC2، HTML publisher و غیره.

مزایای Jenkins

متن باز و جامعه ای بزرگ برای پشتیبانی
نصب آسان
دارای بیش از 1000 پلاگین برای آسان سازی کارها
اگر پلاگینی وجود نداشته باشد، میتوانید آن را کدنویسی کنید و با جامعه به اشتراک بگذارید.
رایگان
ساخته شده با با جاوا

🌐وبینار مدیریت وب سایت های ورد پرسی از طریق cli !?


💡چگونه از طریق بش تمام ساختار های سایت های ورد پرسی را مدیریت کنیم ؟
🤹چگونه از طریق بش کاربر ها را دیده یا کاربر جدید برای سایت ورد پرسی ایحاد کنیم ؟
🚴‍♂چگونه از طریق بش پلاگین نصب یا فعال و غیرفعال کنیم ؟
🏅چگونه از بش رمز عبور ها ریست کنیم ؟
چگونه از بش wordpress multiuser را مدیریت کنیم ؟
🏆چگونه از بش بدون دسترسی به پایگاه داده از کل جداول بک آپ بگیریم ؟
🚦چگونه امنیت ورد پرس را بهینه کنیم ؟
🛰و همه چیز ورد پرس از طریق بش 🥇

کاملا عملی و کاربردی ، برای همه افراد که با وردپرس در ارتباط هستند

سخنران : مهندس اسمعیل دخت

📆این وبینار چهارشنبه ۱۴ اسفند
⏰ساعت ۲۰-۲۲ برگزار خواهد شد .

📎لینک ثبت نام📎

🌎🌈وبینار Git و ورژن کنترل :

🌩مدیریت نسخه، مکانیزمی جهت ذخیره تغییرات و مدیریت فایل ها در طول زمان است تا در صورت نیاز بتوان در هر زمان به نسخه مشخصی بازگشت. همچنین تعامل بین افراد یک تیم نرم­ افزاری در راستای خودکارسازی فرایندها از دیگر اهداف سیستم­ های مدیریت نسخه است.
از این رو Git به عنوان یکی از محبوب­ ترین و قدرتمندترین سیستم­ های مدیریت نسخه توزیع شده و همچنین از جمله ابزارهای لازم به خصوص برای همه افراد است.
در این وبینار می خواهیم در مورد نرم افزار کدبازی(Open Source) بنام گیت صحبت کنیم.
این نرم افزار به تیم مان اجازه می دهد که بصورت همزمان بر روی یک پروژه کار کنیم

⁉️چرا باید از یک نرم افزار کنترل نسخه استفاده کنیم؟

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

📅این وبینار روز پنجشنبه ۱۵ اسفند ماه
🕰ساعت ۱۹-۲۱ برگزار خواهد شد .

📎لینک ثبت نام 📎

.
با سلام و عرض ادب و احترام،

موضوعش جالب بود و عینا برای شما هم می فرستم ولی اصلا روی تحلیلش اصراری ندارم و مطالب آنرا تائید و یا تکذیب نمی نمایم .


♈️ساعت ۱۲:۰۰ ظهر به وقت محلی بود. ۱۶ مسافر پرواز L-410 هواپیمایی شرکت فیلر درفرودگاه شهر کینشاسا پایتخت جمهوری دموکراتیک کنگو سوار هواپیما شدند.
موتورهای هواپیما محصول کشور جمهوری چک و سال ساخت هواپیما هم ۱۹۹۱ میلادی بود.

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

🔰تمام سر نشینان به جز یک نفر کشته شدند.

♈️تحقیقات ملی و بین المللی شروع شد، همه چی چک شد، و هیچ مشکلی از نظر فنی، کمبود سوخت، عدم قابلیت کنترل توسط خلبان ، وجود نداشت.
همه تعجب کردن و انجمن بین المللی بررسی حوادث هوایی یه تیم تحقیقاتی خبره برای بررسی حادثه ارسال کرد.

♈️بعد از اینکه از همه ی ابزارهای تکنولوژیکی نا امید شدند، تنها امیدشان مسافری بود که توی این حادثه آسیب دیده بود و در بیمارستان بستری بود. سراغ مسافر باقی مونده رفته و ازوی پرسیدند که آیا میتواند کمک کند و بگوید چرا هواپیما سقوط کرد؟

♈️مسافر گفت: دلیل سقوط هواپیما یه بچه تمساح بود!
بچه تمساح؟
یعنی چی؟
مسافر توضیح داد: یکی از مسافرهای هواپیما کارش قاچاق تمساح بوده و همیشه بچه تمساح ها را داخل کیف دستیش میگذاشته و با خودش میاورده داخل هواپیما تا بتواند به شهرهای دیگه ببرد و به توریستها و شرکتها بفروشد.

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

♈️با اضافه شدن بیش از ۱۰۰۰ کیلو وزن به دماغه ی هواپیما، سر هواپیما به سمت پایین می آید، بچه تمساح باز سر میخورد و به سمت جمعیت می رود.
جمعیت با دیدن بچه تمساحی که به سمتشون می آمده بیشتر میترسند و همه سعی می کنند داخل کابین خلبان بروند.

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

♈️به محض شنیدن این حرف، تیم جستجو دوباره منطقه را به دقت میگردد و جنازه ی بچه تمساح را پیدا میکنه.

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

🔰بعد از خواندن این حادثه ی عجیب هوایی به خودم گفتم:

♈️ترس دیدن بچه تمساح، از خود بچه تمساح خطرناک تر بوده!
بعد به زندگی نگاه کردم و دیدم نه فقط توی ان هواپیما این واقعیت تلخ وجود داشته، بلکه تو تمام مراحل زندگی ممکن است این اتفاق رخ بدهد.

♈️واقعیت این است که برای هر مشکل و هر وضعیت خطرناکی
نه تنها یک راه حل بلکه چندین راه حل وجود دارد.

♈️اما تا به امروز هیچ راه حل و دارویی برای ترس از خطر، کشف نشده.

♈️در واقع مردم اکثرا به خاطر ترس از خطر میمیرند نه به خاطر خود خطر.

♈️سکته هایی که بر اثر فکر کردن و ترس از مشکلات رخ میدهد ، هیچ وقت در مواجه ی واقعی با مشکلات رخ نمیدهد!

♈️ایرانی جماعت هم استاد ترس از مشکلات هستند واقعا.

♈️خیلی از ما فقط به خاطر ترس از عدم موفقیت، کاری که آرزو یش را داریم شروع نمیکنیم.

♈️خیلی از ما از ترس آینده حاضر نیستیم به آینده مان فکر کنیم.

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

♈️متاسفانه مردمان امروز ما مثل مسافرین پرواز L410 با دیدن کوچکترین مشکلات بدترین عکس العملها را از خودشون نشان میدهند و همگی به سمت سر هواپیما فرار میکنند و باعث سقوطش میشوند.

♈️کاش ماهم مثل مسافری که با دیدن بچه تمساح منطقی فکر کرد و فهمید که این بچه تمساح نمیتواند آسیبی به کسی برساند،‌ بفهمیم که هرمشکلی که بوجود می اید قرار نیست همه ی ما را ازبین ببرد و خیلی وقتها مشکلات باتصمیم گیری درست وحفظ آرامش به راحتی قابل حل است.

♈️یادمان نرود،ما انسانها فقط ۱ بار قراراست بمیریم ، پس تاوقتی نمردیم اینقدر روزمره خودمون را نکشیم و زندگی کنیم.

♈️ولی کاری که جامعه ی ما این روزها با خودش میکند واقعاجای تاسف دارد.

♈️نه فقط بچه تمساح بلکه، با دیدن یه مارمولک هم دست و پایمان راگم میکنیم و دستی دستی خودمان را به کشتن میدهیم.
.

خبر خوب :


🔴 پنجمین محموله کیت‌های تشخیصی وارد ایران شد.

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