- Главная
- Разное
- Дизайн
- Бизнес и предпринимательство
- Аналитика
- Образование
- Развлечения
- Красота и здоровье
- Финансы
- Государство
- Путешествия
- Спорт
- Недвижимость
- Армия
- Графика
- Культурология
- Еда и кулинария
- Лингвистика
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Детские презентации
- Информатика
- История
- Литература
- Маркетинг
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Humans By The Hundred презентация
Содержание
- 1. Humans By The Hundred
- 2. $ whoami SRE Manager at Yelp CWRU Alum Pittsburgh native
- 3. Yelp’s Mission: Connecting people with great local businesses.
- 4. Yelp Stats: As of Q2 2015
- 5. What is Yelp? Many sites: www, m,
- 6. Why Am I Here?
- 8. DATA
- 9. This talk is about people
- 17. The Goal
- 18. Iterate as fast as possible
- 19. Regardless of how many people are participating
- 20. Deployment
- 21. How It Starts
- 22. Deployment: the early days Get a few
- 25. Things get slower... Tests take longer to
- 26. The Problem: Humans Are Fallible
- 27. The Problem: Humans Are Fallible “…oh @$#&”
- 29. The Problem, With Math Assume: Every change
- 30. The Problem, With Math Only you p
- 31. The Problem, With Math p = (.98)n
- 32. The Problem, With Math p = (.98)n exponential decay!
- 34. This doesn’t scale! More developers = more
- 35. Mitigating Exponential Decay p = (.98)n
- 36. Mitigating Exponential Decay p = (.98)n
- 38. Making it harder to screw up Write
- 39. Just write better software and stop making mistakes!
- 40. PROBLEM SOLVED
- 42. The Real World Testing builds confidence in
- 43. Mitigating Exponential Decay p = (.98)n
- 44. Mitigating Exponential Decay p = (.98)n
- 45. Service-Oriented Architecture Large monolith → smaller services
- 46. Service-Oriented Architecture Benefits Smaller code bases =
- 47. Service-Oriented Architecture Drawbacks everything becomes decoupled function
- 48. SOA scales people, not code.
- 49. Conquering SOA With the monolith, it’s easy to focus on mean time between failures (MTBF)
- 50. Conquering SOA In a SOA, focus on mean time to recovery (MTTR)
- 51. Conquering SOA Fail fast Anticipate failure Leverage iteration speed to recover fast
- 52. Conquering SOA Treat everything as distributed That
- 53. Reaping the Benefits Smaller failure domains Fewer
- 54. Reaping the Benefits Smaller changes means smaller
- 55. Continuous Delivery Everyone works against master branch
- 56. PROBLEM SOLVED
- 57. Testing
- 58. Tests are hard to get right.
- 65. How can we do better?
- 67. “Not Recommended” Tests
- 68. “Not Recommended” Tests If a test fails
- 69. Reliable tests >> test coverage.
- 70. Don’t always run all the tests!
- 71. Tests of external services should be monitoring
- 72. Define your boundaries.
- 73. yelp.com / dataset_challenge 61K businesses
- 74. @YelpEngineering YelpEngineers engineeringblog.yelp.com github.com/yelp
- 75. yelp.com/careers
- 76. Questions?
$ whoami SRE Manager at Yelp CWRU Alum Pittsburgh native
Слайд 5What is Yelp?
Many sites: www, m, biz, api
Mobile apps
Partner platform
Hundreds of
developers
Thousands of servers
Thousands of servers
Слайд 22Deployment: the early days
Get a few people together in slack/irc/etc.
Merge up
the code
Run the tests
Manually test it in stage
Cross your fingers
Run the tests
Manually test it in stage
Cross your fingers
Слайд 25Things get slower...
Tests take longer to run
More hosts = longer downloads
More
developers = more eyeballs
More features = more code
More features = more code
Слайд 29The Problem, With Math
Assume:
Every change has a chance of success: 98%
That
means no test failures, no reverts, etc.
Every deploy has a number of changes: n
Any failure in the pipeline invalidates the deploy
Let’s figure out the probability of a successful deployment: p
Every deploy has a number of changes: n
Any failure in the pipeline invalidates the deploy
Let’s figure out the probability of a successful deployment: p
Слайд 30The Problem, With Math
Only you
p = .98 (98%)
You and a friend
p
= .98 * .98 = .96 (96%)
You and nine co-workers
p = .98 * .98 * .98 * … * .98 = .82 (82%)
You and nine co-workers
p = .98 * .98 * .98 * … * .98 = .82 (82%)
Слайд 34This doesn’t scale!
More developers = more changes
More changes = longer deploys
Longer
deploys = less time to develop
Less time to develop = slower to iterate
Slower to iterate != the goal
Less time to develop = slower to iterate
Slower to iterate != the goal
Слайд 38Making it harder to screw up
Write more tests
Write better tests
Get better
code reviews
Get better infrastructure
Switch programming languages
Use better tools
Get better infrastructure
Switch programming languages
Use better tools
Слайд 42The Real World
Testing builds confidence in our changes
Testing does not protect
you from failure
Better tools, tests, and infrastructure can raise our success rates
Better tools, tests, and infrastructure can raise our success rates
Слайд 45Service-Oriented Architecture
Large monolith → smaller services
Services communicate over network
Usually HTTP, but
you can do RPC, SOAP, etc.
Service = independent code base
Independent deployments
Service = independent code base
Independent deployments
Слайд 46Service-Oriented Architecture
Benefits
Smaller code bases = upper bound to n
Failure domains become
isolated
Technology independence
Federated responsibility
Technology independence
Federated responsibility
Слайд 47Service-Oriented Architecture
Drawbacks
everything becomes decoupled
function calls start looking like HTTP requests
versioning can
be a nightmare
tracking dependencies is hard
data consistency becomes challenging
end-to-end testing becomes hard(er), if not impossible
tracking dependencies is hard
data consistency becomes challenging
end-to-end testing becomes hard(er), if not impossible
Слайд 52Conquering SOA
Treat everything as distributed
That means everything will fail
Use timeouts, retries
Find
ways to degrade gracefully
Fail fast & isolated
Don’t rely on synchronous processes
Prepare for eventual consistency
Fail fast & isolated
Don’t rely on synchronous processes
Prepare for eventual consistency
Слайд 53Reaping the Benefits
Smaller failure domains
Fewer people & changes to manage
Deploys get
smaller
Deploys get faster
Deploys become continuous
Deploys get faster
Deploys become continuous
Слайд 54Reaping the Benefits
Smaller changes
means smaller code reviews
means faster validation
means smaller blast
radius
means faster iteration
means faster iteration
Слайд 55Continuous Delivery
Everyone works against master branch
Master is deployed when commits added
Deployment
gated by tests
Monitoring knows something is wrong before you do!
Monitoring knows something is wrong before you do!
Слайд 68“Not Recommended” Tests
If a test fails on master:
a feature is broken
on the live website, or
your test sucks and you should ditch it
In either case, we disable it
Ticket is created
Developers can fix it later or just bin it and start fresh
your test sucks and you should ditch it
In either case, we disable it
Ticket is created
Developers can fix it later or just bin it and start fresh
Слайд 73
yelp.com / dataset_challenge
61K businesses
61K checkin-sets
481K business attributes
1.6M reviews
366K users
2.8M edge
social-graph
495K tips
495K tips
Your academic project, research or visualizations, submitted by Dec 31, 2015
=
$5,000 prize + $1,000 for publication + $500 for presenting*
*See full terms on website
Academic dataset from 10 cities in 4 countries!
