精神科醫師都不懂「夢的解析」,但只有佛洛伊德可以撫慰幽暗受苦的心靈

精神科醫師都不懂「夢的解析」,但只有佛洛伊德可以撫慰幽暗受苦的心靈
Photo Credit: Antonio de Pereda Public Domain

我們想讓你知道的是

在今天的精神醫學臨床實務裡,除了精神分析與動力取向心理治療會談到夢境以外,夢的臨床意義只有在睡眠障礙與創傷後壓力症候群的診斷標準裡提到,比如夢遊或惡夢連連等,至於夢的內容,就完全存而不論了。

昨晚做了一個夢,今天白天想起,簡單解析了一下,到了晚上又想到似乎還沒寫過關於夢的文章,便來寫一篇吧。

有人問說自己解析夢境,準嗎?佛洛伊德(Sigmund Freud)的《夢的解析》,裡頭就舉了許多自己的夢境來佐證他的釋夢理論。準不準?佛洛依德不是算命師,他的釋夢方法是要探討潛意識,不是要預測明牌。

而潛意識的定義,就是你自己意識不到,但佛洛伊德看得出來的心理內容。既然如此,你說「不準!我沒有那樣想!」那是因為潛意識內容太令你反感,所以你否認;你說準,那也不算數,因為夢境的表面內容與隱藏內容,是兩條平行線。

自我釋夢,至少在夢境的表面內容是可能的。根據佛洛伊德的理論,夢境的表面內容大都是白天生活經驗或所思所感的沉積物,在腦海裡經過加工製造後,趁著月黑風高你睡著的時候,搬到意識舞台上演。所以說夢境的表面內容大都可以跟白天生活經驗或所思所感做出連結與對應。

當然必須經過一個裝飾、壓縮、重組或整合的過程,把清醒時的內心材料處理以後,然後,重點來了,通過內心小警總的審核機制,才能在夢境裡浮現。警總是戒嚴時代負責沒收黨外報章雜誌書籍的警察單位。

內心小警總是佛洛伊德的精神分析理論最重要的發明之一,也是他用來解析夢境的最重要理論。前面說過夢境有表面內容與隱藏內容,而之所以有這樣的斷裂,就是因為潛意識裡那些太過令自己難堪、擔心、羞愧或痛苦的,可能是發生在好久以前,卻一直在內心角落隱隱刺痛的記憶,必須透過偽裝變成夢境的表面內容,才能通過內心小警總的審查,而以做夢的形式出現。

因此佛洛伊德說,「夢是通往潛意識的王道」。後來釋夢就成了精神分析的重要治療工具。然而隨著精神分析在1950年代左右開始式微,精神科醫生也越來越少人用釋夢來解析病人的性格或情緒了。

在今天的精神醫學臨床實務裡,除了精神分析與動力取向心理治療會談到夢境以外,夢的臨床意義只有在睡眠障礙與創傷後壓力症候群的診斷標準裡提到,比如夢遊或惡夢連連等,至於夢的內容,就完全存而不論了。

為什麼?因為夢的內容太過蕪蔓龐雜,而且必須倚靠當事人主觀回想,要研究十分困難,而且越研究越搞不清楚,於是就漸漸沒有人要探討了。1950年代,美國曾有一位心理學家花了幾十年的時間,記錄與分析了大批受試者的五萬個夢境,想要把佛洛伊德的釋夢理論推向新的境界,如今已沒有人要讀他寫的釋夢之書。

1953年,發生了一件心理學界的大事,就是動眼期睡眠,R.E.M. sleep,被發現了,而動眼期睡眠也就是睡眠的做夢期。很奇怪,發現R.E.M.的三位美國心理學家,竟然沒有得到諾貝爾獎。

R.E.M.這名詞有多響亮?不要說生理學與心理學上的應用,連搖滾樂團都以此為名。R.E.M.樂團的歌曲帶點放浪頹廢詩意,我大學時代很喜歡。R.E.M.的出現,象徵著《夢的解析》必須從精神醫學退位,佛洛伊德必須到一邊涼快去了。

當然三十年前高中時代就在讀佛洛伊德的我不會知道,原來精神科醫師根本都不懂「夢的解析」啊!於是我從大一就有一個紀錄自己夢境的習慣,那時翹課在宿舍睡午覺,夢到被老師點名而嚇醒,便趕緊翻出筆記畫下夢境。

畫下。夢境大多是視覺內容,聽覺比較少,很多時候甚至是無聲夢境。大都是黑白,如果是彩色,那十分幸運。夢裡的人物大都面容模糊,但你就是知道那人是誰;很奇怪,這應該跟做夢的某種心理機制有關,但我從來不知道有誰可以說明。

夢的另一個特點是失去現實感,即使再離譜不可能的內容,做夢時也會信以為真。明明夢境那麼清晰,照理說邏輯推理能力應該也還存在,為什麼不會自我質疑?是不是做夢當下,自我抑制了某些現實內容的回想,以致無法比對現實?

然而有的時候,會有一些夢境不真實到連做夢都難以相信。連做夢都難以相信,那不是最渴求的願望,就是最深沉的創痛。比如父親病逝以後,有好幾年的時間,晚上做夢我會夢到父親帶著健康的身體下班回來,跟我們談談笑笑吃飯看電視,雖然那景象令人開心得微笑,但在夢境裡,你依然可以感受到,在美好景象背後,你仍有一絲絲的質疑與不安:爸爸不是生病開刀了嗎?怎麼還好好的?

然後張開眼睛,你發現自己臉頰垂掛兩行清淚。R.E.M.很科學,很厲害,但它能告訴我們,為什麼我們會夢到死去的親人嗎?不能。只有佛洛伊德可以撫慰幽暗受苦的心靈。

當然還有其他許多心理學理論想要提出釋夢的理論,但大都只能片面說明。基本上從認知科學的角度來看,夢境有很大一部分是亂碼,而亂碼是不可能有規則的。

人類所有文化都對夢境著迷,也有各自的解釋,於是在民俗與宗教裡,也保留了各式各樣對於夢境的說法,在門診裡就經常可以聽到病人抱怨自己怪夢連連,擔心不吉利。

在夢境內容裡,最讓人愉快的經驗之一,應該是飛翔之夢。我做過的飛翔之夢,大都只是從這頭半空盪到那頭,有些像是滑翔,但已經夠令人興奮了。當然春夢也很好,夢到跟同學同事鄰居或朋友做愛,就是不會夢到枕邊人。夢遺是所有男孩子都有的成長經驗,女孩也有相對應的夢境高潮。

因為想做令人愉悅的夢,有一陣子我研究了怎麼孵夢,也就是讓自己隨心所欲做出想要的夢,但當然失敗。為什麼?夢是自我欺騙,而既然自導自演,怎麼還可能被騙?


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡