ฝึกพูดภาษาอังกฤษด้วยเทคนิค Shadowing จากวิดีโอ: I Wish Someone Explained DevOps to Me Like This
เลือกโหมดฝึก
แต่ละโหมดจะเปิดห้องฝึกแบบเต็มจอ
185 ประโยค
หากประโยคสั้นหรือยาวเกินไป กดที่ Edit เพื่อปรับแก้
1
Imagine an IT company has been hired to build a loan management system for a bank.
2
It will record loan details, track approvals, and manage repayment information.
3
The developers are ready to write code, but there is no environment to run it in, no connection to the bank's existing systems,
4
and no clear way to release or monitor it once it is live.
5
Where should the team begin, and how do all the parts fit together?
6
That's what DevOps is for.
7
For years, developers focused on building features, while operations teams focused on keeping production stable.
8
Agile helped teams deliver smaller changes, and continuous integration helped developers combine their work more often.
9
But teams still needed to cooperate when software was released and supported.
10
The DevOps movement gathered momentum in 2009.
11
That year, John Alspaugh and Paul Hammond spoke about cooperation between development and operations at Flickr,
12
and Patrick Dubois helped organize the first DevOps Days event in Ghent.
13
The name caught on, but the idea was bigger than a job title or a toolset.
14
People who build and run software need to work together throughout the life of the software.
15
DevOps is now a popular role in technology.
16
In this video, we'll explore its ecosystem in 10 sections, from infrastructure and networking, to security, containers, and releases.
17
We'll follow James, a DevOps engineer hired by the IT company.
18
His job is to help the developers, security specialists, and bank operations team build, release, and run the loan management system reliably.
19
The first question is where the system will run.
20
The bank and IT company need to decide whether to use the bank's own data center, a cloud provider such as AWS,
21
Azure, or Google Cloud, or a combination.
22
Their choice depends on the bank's existing systems, security rules, costs, and where its data is allowed to live.
23
At the beginning, the project has no servers, cloud accounts, access rules, or test environments.
24
Cloud, platform, or DevOps engineers often work with the bank's infrastructure and security teams to prepare the foundation.
25
This is commonly called a landing zone.
26
Think of it as preparing a new building before the project moves in.
27
It can include cloud accounts or subscriptions, basic network design, access rules, central logging and security controls.
28
For the loan project, the team might have separate accounts or subscriptions for development, testing and production.
29
This helps keep the environments organized and limits the effect of a mistake in one area.
30
The bank may already have a landing zone, in which case James' team works within it and adds only the parts the project needs.
31
James uses Infrastructure as Code, or IAC, to describe the resources the project needs.
32
With Terraform, for example, he can write instructions for creating a test environment, its network, and its servers.
33
The team reviews those instructions and then applies them to create the environment.
34
If it needs another test environment later, it can use the same instructions instead of rebuilding everything by hand.
35
AWS CloudFormation and Azure Bicep are other tools for defining cloud infrastructure.
36
The landing zone gives the project a safe place to run, but it still needs connections to the bank's existing systems.
37
That brings James to the next area, networking.
38
Networking connects the loan management system to the people and systems that need to use it.
39
You can think of it as the roads and gates between different parts of the bank's technology.
40
The network must provide the necessary routes while controlling which systems and people are allowed through.
41
The loan system might need to connect to the bank's identity service, database, and existing financial systems.
42
Developers may need a controlled way to reach a test environment, but that does not mean the environment should be open to everyone on the Internet.
43
A network includes subnets, which divide it into smaller areas, firewalls, which allow or block connections,
44
and DNS, which helps systems find each other by name.
45
A load balancer directs incoming requests to available servers, much like a traffic controller sending cars toward open lanes.
46
A private connection, or VPN, can provide a controlled route between the IT company's environment and the bank's network.
47
Cloud providers offer network services, such as AWS VPC and Azure Virtual Network.
48
Teams might also use NGINX or HAProxy to route traffic.
49
James works with the bank's network team to make sure the loan system can reach the services
50
it needs without opening unnecessary paths into the bank's network.
51
With the environment and its connections planned, the team needs a shared way to record how the software and its setup change over time.
52
That's what we're going to see next.
53
source control, and configuration.
54
Developers use Git to keep a history of their code.
55
It works like a shared history book.
56
The team can see what changed, who changed it, and when.
57
Platforms such as GitHub, GitLab, and Bitbucket give the team a place to store Git repositories and review proposed changes.
58
For example, when a developer changes how the system calculates a repayment, another team member can review the change before it is added to the project.
59
If a problem appears later, the team has a record it can use to investigate.
60
The system also needs different settings in different environments.
61
The development version might connect to a test database, while the production version connects to the bank's live database.
62
These settings are called configuration.
63
James helps the team keep them separate from the application code so that the right settings are used in the right place.
64
Tools such as Ansible can also apply consistent settings to servers.
65
The team can keep infrastructure definitions and pipeline instructions in Git too.
66
That way, it can review a proposed change to an environment just as it reviews a proposed change to the application.
67
The team can see what is changing before it is applied.
68
Now the team can track its code and configuration changes.
69
But how can it quickly tell whether a new change works or whether it has broken something else?
70
That brings us to continuous integration and testing.
71
Continuous Integration, or CI, means bringing changes together frequently and checking them automatically.
72
James sets up a pipeline, a sequence of automated steps, that runs when a developer submits a change.
73
It might build the application, check its formatting, and run tests.
74
Jenkins, GitHub Actions, GitLab CI, and Azure Pipelines are common tools for running this kind of pipeline.
75
Different tests check different parts of the system.
76
A unit test checks a small piece of code, such as a repayment calculation.
77
An integration test checks whether parts work together, such as the application connecting to its database.
78
A broader test can check a complete process, such as recording a repayment and updating a loan record.
79
The team can also run performance tests to see how the system behaves when it has a lot of work to do.
80
For instance, can it process the bank's expected number of repayment records during the overnight window?
81
If a test finds a problem, the team can fix it before the change moves further.
82
The pipeline gives the team regular feedback instead of saving all testing for the end of the project.
83
When a change passes its checks, the team needs a reliable way to store exactly what it built.
84
That brings us to package and artifact management.
85
Most applications use software components created by other teams.
86
A Java project might use libraries for connecting to a database, while a JavaScript project might use packages for its interface.
87
A package manager downloads those components and keeps track of their versions.
88
Maven and Gradle are common in Java projects, while NPM is common in JavaScript projects.
89
When the loan system is built, the result is a package, also called an artifact, that the team can test and release.
90
Tools such as JFrog Artifactory and Sonatype Nexus store artifacts so the team can retrieve them later.
91
They also help track which versions of outside libraries went into the build.
92
James encourages the team to build the release package once, test it, and then move that same package through the environments.
93
If they build one package for testing and a different one for production,
94
it becomes harder to know whether the bank is getting the version that was actually tested.
95
The team can now identify and store the software it built.
96
The next question is how to make sure that software runs consistently on different computers and environments.
97
That leads us to containers and orchestration.
98
A container packages an application in a form that can run consistently in different environments.
99
Docker is a popular tool for building containers.
100
Think of a container as a labeled box carrying the application and the pieces it needs to run.
101
James' team can use a container for the loan system in development, test it, and then use the same container image when preparing a release.
102
This helps reduce differences between the project's test environment and the bank's production environment.
103
If there are many containers running across many machines, the team may need a system to manage them.
104
Kubernetes can schedule containers, restart them if they fail, and coordinate updates.
105
It can also be configured to add or remove capacity as demand changes.
106
Docker helps package containers.
107
Kubernetes helps manage them across a group of machines.
108
The bank project might use Kubernetes if its needs and approved platform call for it, or it might use a simpler managed service or virtual machines.
109
Whatever platform the team chooses, it still needs to protect the application and the information it handles.
110
That brings us to security.
111
The loan system handles important bank information, so the team needs to control who can access it and protect the information it uses.
112
Security is part of building and running the system, not just a check added before launch.
113
The team gives each person and service only the access it needs.
114
A developer might need access to a test environment, for example, without having unrestricted access to production.
115
Passwords, keys, and other secrets should be stored securely, rather than written into the code.
116
HashiCorp Vault and Cloud Secret Management Services can help manage them.
117
James also adds security checks to the pipeline.
118
Code scanning looks for common mistakes in the project's own code.
119
Dependency scanning checks whether the outside libraries the project uses have known security problems.
120
Container scanning checks the packaged application for vulnerable components.
121
These tools cannot guarantee perfect security, but they can help the team find and fix many issues earlier.
122
The team works with the bank's security specialists to decide
123
which checks are needed and what should happen if a check finds a problem.
124
They also agree how to protect information as it moves between systems and how to avoid exposing sensitive details and logs.
125
Building security into the development and release process is often called DevSecOps.
126
Once the team has built and checked a secure package, it needs to decide how that package will move into the bank's environment.
127
Now we come to releases and deployments.
128
A release is a version of the software the team intends to make available.
129
A deployment is the process of putting that version into an environment where it can run.
130
Continuous delivery means keeping software ready for release through an agreed process.
131
Continuous deployment goes further by automatically releasing changes that pass the required checks.
132
The bank may require a person to approve each production release, but the pipeline can still build the software,
133
run checks, and prepare the release for that approval.
134
The important part is that the steps are clear and repeatable.
135
Teams can also introduce a new version gradually.
136
With a canary release, the new version handles a small amount of work first.
137
If it behaves as expected, the team sends more work to it.
138
A rolling deployment updates parts of the system one at a time,
139
while a blue -green deployment prepares the new version alongside the old one before switching over.
140
James works with the bank to choose a release method that fits its system and rules.
141
They agree on the required checks, approvals, and release windows.
142
Once the software is deployed, the team needs to know how it behaves, so its attention moves to monitoring and incident response.
143
Monitoring helps the team see whether the running system is healthy and alerts them when something needs attention.
144
James wants to know, for example, if an overnight repayment process is falling behind or taking longer than expected.
145
The team uses metrics to measure things over time, such as how long a process takes.
146
Logs record events that happened, and traces show the path a request took through different parts of the system.
147
Together, these signals help the team understand both that something went wrong and where to investigate.
148
Tools such as Prometheus and Grafana can collect and display metrics.
149
OpenTelemetry can help gather information from applications, while systems such as Elastic or Splunk can help teams search logs.
150
Cloud providers also offer monitoring services.
151
An alert should give the team a reason to act.
152
If the repayment process is falling behind, the right people need to know and have a starting point for investigating.
153
James helps the team write runbooks, practical guides for common issues, and agree who should respond to an incident.
154
Monitoring helps the team notice and investigate a problem.
155
The team also needs a plan for larger failures, such as damaged data or an unavailable environment.
156
That takes us to reliability, recovery, and cost.
157
The bank and IT company agree how quickly the loan system should be restored after a serious failure
158
and how much recent data it can afford to lose.
159
The team backs up important data and practices restoring it.
160
A backup is only useful if the team knows how to use it and has checked that it works.
161
The team also sets a reliability target, such as how reliably an overnight process should complete and checks whether the system is meeting it.
162
If problems happen too often, the team may need to focus on improving reliability before taking on more changes.
163
This kind of focus on dependable services is associated with site reliability engineering, or SRE.
164
Cost needs attention too.
165
Cloud resources can be added when needed, but resources left running unnecessarily can keep increasing the bill.
166
James helps the team review what it is using, plan for busy periods, and remove resources it no longer needs.
167
Paying attention to cloud costs is often called FinOps.
168
As the IT company takes on more projects, James may help create a shared platform with useful starting points,
169
a code repository, test environment, pipeline, and security checks.
170
That saves new teams from repeating the same setup and helps them start with practices the company already understands.
171
Now we can see how the 10 areas connect.
172
Infrastructure gives the system a place to run, and networking connects it to the bank's systems.
173
Source control tracks changes, CI tests them, and package management stores what the team has built.
174
Containers help the software run consistently, security checks help protect it, and release practices move changes into production in a controlled way.
175
Monitoring, recovery, and cost planning help the team operate it over time.
176
Different projects use different tools.
177
One team might use Terraform and Jenkins.
178
Another might use a cloud provider's tools and GitHub Actions.
179
The important thing is to understand what each part is for and choose tools that fit the project.
180
That is the DevOps ecosystem.
181
People, practices, and tools working together to build, release, and operate software.
182
When you look at a DevOps roadmap, ask what problem each area solves and how it connects to the others.
183
Once you understand that, the tools become much easier to learn.
184
If this helped you connect the pieces, consider subscribing.
185
We'll keep exploring the tools and ideas behind modern software, one project at a time.
ดาวน์โหลดแอป
ทุกอย่างที่ต้องใช้เพื่อพูดได้คล่อง
AI ให้คะแนนการออกเสียงให้คะแนนทุกประโยค
ฝึก IPAเชี่ยวชาญทุกเสียง
คำศัพท์สร้างคลังคำของคุณ
เกมคำศัพท์เล่นไปเรียนไป
ช่องเดียวกัน
FOR YOU
วิดีโอแนะนำ
C11
78 ประโยค
How I deploy serverless containers for free
Daily ConversationUniversity StudentsWorking Adults
C12
4 ประโยค
What is Event Driven Architecture (EDA)?
Daily ConversationUniversity StudentsWorking Adults
C14
62 ประโยค
"Customer Obsession" Leadership Principle Explained by Amazon CEO Andy Jassy
Daily ConversationUniversity StudentsWorking Adults
C11
150 ประโยค
Parallel Pump Operation
Daily ConversationUniversity StudentsWorking Adults
C13
148 ประโยค
900+ hours of Learning AI Agents in 9 Minutes
Daily ConversationUniversity StudentsWorking Adults
C11
509 ประโยค
The Digital Transformation of Banking and Financial Services in a New Era
Daily ConversationUniversity StudentsWorking Adults
C14
127 ประโยค
How to design a Deployment Pipeline (GitOps)
Daily ConversationUniversity StudentsWorking Adults
C11
176 ประโยค
Every Networking Concept Explained | Networking 101 (2026)
Daily ConversationUniversity StudentsWorking Adults
C11
346 ประโยค
Trust the Process: How to Design Teams That Actually Work
Daily ConversationUniversity StudentsWorking Adults
C11
180 ประโยค
Armchair Architects: Resiliency in the Cloud – Core Patterns
Daily ConversationUniversity StudentsWorking Adults
C12
340 ประโยค
Claude Code Mods Explained: Customize Your Setup
Daily ConversationUniversity Students
C11
40 ประโยค
The Engineering that Runs the Digital World 🛠️⚙️💻 How do CPUs Work?
Daily ConversationUniversity StudentsWorking Adults
คำศัพท์และข้อสังเกตด้านการพูดสำหรับบทเรียนนี้
บทเรียนฝึกพูดนี้ใช้วิดีโอ “I Wish Someone Explained DevOps to Me Like This” เป็นสื่อ คำที่ถูกพูดซ้ำบ่อยที่สุด: environment, test, project, release, James วิดีโอนี้มี 185 ประโยค และ 2655 คำ สำหรับฝึกพูดตาม ช่วงที่มีเสียงพูดยาว 16:28 ผู้พูดพูดด้วยความเร็วเป็นธรรมชาติ ประมาณ 161 คำต่อนาที ใกล้เคียงกับบทสนทนาในชีวิตประจำวัน มีเพียง 81% ของคำที่อยู่ใน 3,000 คำที่ใช้บ่อยที่สุดในภาษาอังกฤษ คำศัพท์จึงค่อนข้างยาก
คำศัพท์สำคัญในวิดีโอนี้
คำที่ควรเรียนรู้ 15 คำจากวิดีโอ พร้อมคำอ่านและความหมาย:
| คำศัพท์ | คำอ่าน | ความหมาย |
|---|---|---|
| package คำนาม | /ˈpæk.ɪd͡ʒ/ | หีบห่อ, ห่อ |
| cloud คำนาม | /ˈklaʊ̯d/ | เมฆ |
| container คำนาม | /kənˈteɪ.nəɹ/ | บรรจุภัณฑ์, หีบห่อ |
| connect คำกริยา | /kəˈnɛkt/ | เชื่อม, ต่อ |
| infrastructure คำนาม | /ˈɪnfɹəˌstɹʌkt͡ʃə/ | โครงสร้างพื้นฐาน |
| monitor คำนาม | /ˈmɑ.nɪ.tɚ/ | จอภาพ, หน้าจอ |
| database คำนาม | /ˈdeɪtəˌbeɪs/ | ฐานข้อมูล |
| server คำนาม | /ˈsɝvɚ/ | เซิร์ฟเวอร์ |
| log คำนาม | /lɔɡ/ | ซุง, ท่อน |
| investigate คำกริยา | /ɪnˈvɛs.tə.ɡeɪt/ | สืบ, สืบสวน |
| behave คำกริยา | /bɪˈheɪv/ | ประพฤติ, ทำตัว |
| hire คำกริยา | /ˈhaɪɹ/ | จ้าง |
| explore คำกริยา | /ɪkˈsploɹ/ | สำรวจ |
| specialist คำนาม | /ˈspɛʃəlɪst/ | ผู้เชี่ยวชาญ |
| metric คำคุณศัพท์ | /ˈmɛt.ɹɪk/ | เมตริก |
ไวยากรณ์ในวิดีโอนี้
โครงสร้างที่ผู้พูดใช้บ่อยที่สุด พร้อมคำพูดจริงจากวิดีโอ:
| โครงสร้าง | ในวิดีโอ |
|---|---|
| Passive voice be + กริยาช่อง 3 — เน้นสิ่งที่เกิดขึ้น ไม่ใช่ผู้กระทำ | has been hired · was released · is allowed |
| Present perfect have/has + กริยาช่อง 3 — เหตุการณ์ในอดีตที่ยังเกี่ยวข้องกับปัจจุบัน | has been hired · has broken · have known |
การออกเสียงที่ควรระวัง
ผู้พูดใช้รูปย่อและรูปลดเสียง 4 ครั้ง เช่น we'll, we're ให้พูดแบบสั้นตามที่ได้ยิน
- เสียง “sh” และ “zh”: integration /ˌɪn.tɪˈɡɹeɪ.ʃən/, instruction /ɪnˈstɹʌkʃən/, configuration /kənˌfɪɡ.əˈɹeɪ̯.ʃən/, specialist /ˈspɛʃəlɪst/, subscription /səbˈskɹɪpʃən/
- คำยาว — ลงเสียงหนักให้ถูกพยางค์: developer /dɪˈvɛləpɚ/, infrastructure /ˈɪnfɹəˌstɹʌkt͡ʃə/, continuous /kənˈtɪn.juː.əs/, investigate /ɪnˈvɛs.tə.ɡeɪt/, integration /ˌɪn.tɪˈɡɹeɪ.ʃən/
เสียงที่คนไทยมักออกเสียงยาก:
- เสียงท้ายคำ — ออกเสียงให้ครบ ไม่เปลี่ยนเป็นตัวสะกดแบบไทย: package /ˈpæk.ɪd͡ʒ/, database /ˈdeɪtəˌbeɪs/, continuous /kənˈtɪn.juː.əs/, behave /bɪˈheɪv/, virtual /ˈvɜɹt͡ʃuəl/
- /v/ — ไม่ใช่ /w/ ให้ฟันบนแตะริมฝีปากล่าง: developer /dɪˈvɛləpɚ/, server /ˈsɝvɚ/, investigate /ɪnˈvɛs.tə.ɡeɪt/, overnight /əʊvə(ɹ)ˈnaɪt/, provider /pɹəˈvaɪ.də(ɹ)/
- /z/ — เสียงก้อง ไม่ใช่ /s/: expose /ɪkˈspoʊz/, organize /ˈɔɹɡənaɪz/, lanes /leɪnz/, repository /ɹɪˈpɒz.ɪ.t(ə.)ɹɪ/
วิธีฝึกกับวิดีโอนี้
- ฟังวิดีโอให้จบหนึ่งรอบโดยยังไม่ต้องพูด แล้วจดคำที่ยังไม่รู้จัก
- เริ่มที่ความเร็ว 0.75× พูดตามทีละประโยค แล้วกลับไปใช้ความเร็วปกติเมื่อเริ่มคล่อง
- อัดเสียงตัวเองแล้วเทียบกับต้นฉบับ โดยสังเกตคำอย่าง package, cloud, container เป็นพิเศษ
เทคนิค Shadowing คืออะไร?
Shadowing เป็นเทคนิคการเรียนรู้ภาษาที่ได้รับการรับรองทางวิทยาศาสตร์ พัฒนาขึ้นสำหรับการฝึกนักแปลมืออาชีพ วิธีการนี้เรียบง่ายแต่ทรงพลัง: คุณฟังเสียงภาษาอังกฤษจากเจ้าของภาษาและพูดตามทันที — เหมือนเงาที่ตามผู้พูดด้วยช่วงเวลาห่าง 1-2 วินาที การวิจัยแสดงว่าเทคนิคนี้ปรับปรุงความแม่นยำในการออกเสียง ทำนองเสียง จังหวะ การเชื่อมเสียง การฟังเข้าใจ และความคล่องแคล่วในการพูดได้อย่างมีนัยสำคัญ