Symfony y 3 millones de usuarios, nuestro dia a dia
Descargar como KEY, PDF4 recomendaciones759 vistas
El documento habla sobre la filosofía y prácticas de IT de Ofertix, una compañía que vende productos y servicios en internet. Ofertix usa Symfony para su código y tiene aproximadamente 5 millones de visitas mensuales y envía 90 millones de correos electrónicos al mes. El documento describe sus principios de minimizar tecnologías, ser autosuficientes, y tener claro su dirección tecnológica. También cubre temas como arquitectura, despliegues, base de datos, envío de correo y
Symfony y 3 millones de usuarios, nuestro dia a dia
- 1. Symfony y 3 millones de usuarios, nuestro día a día Jordi Llonch <[email protected]>
- 5. ¿Código?
- 6. ¿Código? NO
- 7. ¿Técnicas?
- 9. ¿Filosofía?
- 12. ¿Lo más interesante? Vuestras preguntas
- 14. El proyecto
- 15. Vendemos productos y servicios a precios interesantes por internet
- 16. Cada día abrimos 2-6 pequeñas tiendas durante 3-4 días
- 18. Nuestros usuarios entran de golpe (cuando ven nuestro email)
- 19. Algunos números • 5M visitas únicas mensuales. • 100M páginas servidas/mes. • 90M de correos enviados cada mes • 50k pedidos al mes
- 20. Sólo contamos con nuestros recursos
- 21. Alcance
- 22. sistemas frontal backoffice mailing SO BBDD SEO CRM programación red serv. web caché tickets generación masiva granja PHP monitorización SCM envío masivo SMTP SAN producción campañas firma backup NoSQL Marketing gestión de Cachés la lista de correo monitorización mini cloud privado VPNs
- 23. Alcance x 2
- 24. Principios IT
- 25. Minimizar las tecnologías que usamos
- 28. Somos los únicos responsables de IT
- 30. Intentamos tener claro dónde queremos llegar pero sabemos que hoy no llegamos
- 32. COTS
- 33. COTS Nos mola lo estándar
- 35. Nuestro equipo de I+D
- 36. Nuestro código
- 37. ¡es symfony!
- 38. ¿porqué?
- 39. estandarización
- 40. productividad
- 41. lo escribimos desde 0 en 6 meses
- 43. 2 programadores
- 44. A tener en cuenta
- 45. clases doctrine modelo != clases lógica negocio
- 48. Encapsula lo que va a cambiar y lo que necesites probar
- 49. Escribe código para los otros compañeros no para el compilador
- 50. Arquitectura
- 51. Servidores web y granja de renderización PHP
- 52. INTERNET FRONTALES CONTENIDO ESTATICO RENDERIZADORES PHP BASE DE DATOS Caché SMTP Workers de procesos
- 53. Sesiones
- 54. memcached
- 55. Cache
- 56. Cacheamos: • Partes de la web que pueden ser estáticas (por ej. proceso de compra) • Información relativa a negocio muy usada pero que no es necesario que esté actualizada • assets (css, js, imágenes...)
- 57. memcached redis
- 58. Invalidación de caché • del proceso de compra (invalida la app) • de asset (invalida nuestro script deployer)
- 59. Envío de mail
- 60. Requisitos
- 61. Cada noche envía 3 millones de emails
- 64. ¿cómo?
- 65. Lo hacemos en 2 pasos (decoupling)
- 66. 1r paso
- 67. Seleccionamos todos los destinatarios y generamos el contenido
- 68. Seleccionamos todos los destinatarios y generamos el contenido Tardamos 1 hora
- 69. 2º paso
- 71. ¿cómo?
- 72. • Varios procesos concurrentes cogen packs de emails y los entregan a los servidores SMTP • Los servidores SMTP los entregan a los destinos • Firmamos con DKIM utilizando el clúster de renderización PHP
- 73. Entregamos en 3 horas
- 74. Entregamos en 3 horas Si Hotmail nos deja...
- 75. Data warehouse
- 76. Necesitamos medir para tomar decisiones
- 77. recolección de datos desde la BBDD réplica
- 78. Cargamos los datos en un copo de nieve en un MySQL dedicado
- 79. Los años pasan y se nos piden cosas nuevas...
- 80. ergo
- 81. La base de datos evoluciona y el código también
- 84. En el99% de las migraciones añadimos campos
- 85. si la tabla es pequeña < 300 Mb ó < 300k registros
- 86. ejecutamos migración y actualizamos código
- 87. si la tabla es grande
- 88. ejecutamos migración a las 4:00h
- 89. lo hemos hecho 4 veces
- 90. y la gente compra a esas horas...
- 91. Vale, y con el código?
- 92. Cada programador es responsable de su código
- 94. Deployamos 5 o 6 veces al día
- 95. A veces fallamos y tenemos que correr
- 96. por eso tenemos un MTTR muy bajo
- 97. ¿Cómo?
- 99. Desarrollo en Sf2 :)
- 100. Ideas basadas en capistrano
- 101. Requisitos
- 103. • Adaptar configuraciones para producción
- 104. • Adaptar configuraciones para producción • Verificaciones del código y configuración
- 105. • Adaptar configuraciones para producción • Verificaciones del código y configuración • Deploy en 8 servidores simultáneamente
- 106. • Adaptar configuraciones para producción • Verificaciones del código y configuración • Deploy en 8 servidores simultáneamente • 4 tipos de deploy
- 107. • Adaptar configuraciones para producción • Verificaciones del código y configuración • Deploy en 8 servidores simultáneamente • 4 tipos de deploy • Migraciones de la base de datos
- 108. • Adaptar configuraciones para producción • Verificaciones del código y configuración • Deploy en 8 servidores simultáneamente • 4 tipos de deploy • Migraciones de la base de datos • Rollback
- 109. ¿cómo?
- 110. script preparación de código
- 111. subimos código vía git
- 112. aplicación de deploy • download • code2production • migrate • rollback • status
- 113. mi gato poniendo código en producción
- 114. Organización
- 115. Equipo humano
- 116. • 1 responsable de IT • 5 programadores PHP • 1 programador .NET y android • 1 project leader • 1 administrador de sistemas
- 117. ratios • 1 programador / 600 k usuarios • 1 administrador de sistemas para cada 3M de usuarios ;) • 1 servidor para cada 250 k usuarios
- 118. FIN Autores: Joan Valduvieco Jordi Llonch
- 119. ¿Quién se apunta?
- 120. Gracias
Notas del editor
- #2: \n
- #3: \n
- #4: \n
- #5: \n
- #6: \n
- #7: \n
- #8: \n
- #9: \n
- #10: \n
- #11: \n
- #12: \n
- #13: \n
- #14: \n
- #15: \n
- #16: \n
- #17: \n
- #18: Aqu&#xED; explicar que &#xE9;s Ofertix.\nI r&#xE1;pidament com funciona.\nExplicar que &#xE9;s com obrir petites botigues cada dia (microsites). (s&#x2019;enlla&#xE7;ar&#xE0; amb q podem invalidar caches a nivell de microsite)\n
- #19: \n
- #20: \n
- #21: \n
- #22: \n
- #23: Servidor web = NGINX\nGranja PHP = php-fpm\nLog&#xED;stica t&#xE9; molt de pes al projecte. Pantalles molt complexes amb Sencha.\nSCM = Supply Chain Management\n
- #24: \n
- #25: \n
- #26: Nos permite dominar nuestras herramientas y sistemas. Pocas dependencias.\nAdem&#xE1;s nuestros programadores son m&#xE1;s polivalentes.\n
- #27: \n
- #28: Vendemos en internet si la web no va, no comemos.\nTenemos los m&#xED;nimos proveedores externos. Ellos no est&#xE1;n tan comprometidos con nuestro negocio como nosotros.\n
- #29: \n
- #30: No tiramos c&#xF3;digo, lo evolucionamos.\nNos pensamos muy bien las cosas antes de decidir que debemos desarrollar algo.\n
- #31: \n
- #32: Cheap Off The Shelf\nTecnolog&#xED;as simples y gen&#xE9;ricas.\nPodr&#xED;amos utilizar powermta, o una aplicaci&#xF3;n de datawarehouse o un framework propio hecho de oro...\nEsto no mola del todo pq hacemos pocos desarrollos que podamos publicar para que otros los usen.\n\n
- #33: \n
- #34: \n
- #35: \n
- #36: \n
- #37: teniamos la idea de aumentar el equipo de programadores\ny evolucionar el c&#xF3;digo\ny no quer&#xED;amos reinventar la rueda\n\n\n
- #38: \n
- #39: desarrollo en paralelo a la operaci&#xF3;n de ofertix1. \nNo paramos de vender.\nHemos evolucionado ese desarrollo durante 2 a&#xF1;os y pico\n
- #40: \n
- #41: \n
- #42: \n
- #43: Ponemos eventos en las partes susceptibles de ser ampliadas. Sobretodo para notificaciones o acciones a realizar cuando pasa alguna cosa.\n
- #44: Para generar documentaci&#xF3;n.\nProcesos de preparaci&#xF3;n de elementos de la web (pej fotograf&#xED;as)\n\n
- #45: \n
- #46: No tenemos problemas de rendimiento por c&#xF3;digo mal escrito (si acaso por malas ideas). Pero si que podemos tener problemas de &#x201C;rendimiento&#x201D; en el desarrollo si quien tiene que tocar tu c&#xF3;digo no lo entiende.\n
- #47: \n
- #48: \n
- #49: \n
- #50: \n
- #51: Putada si tenemos que reiniciar, pero eso no ha pasado nunca. Lo meteremos en Redis, alg&#xFA;n d&#xED;a.\n
- #52: \n
- #53: \n
- #54: Memcached va a morir.. Nuestro futuro es redis. Estamos en ello.\n
- #55: \n
- #56: \n
- #57: \n
- #58: \n
- #59: Datos de clientes, ofertas exclusivas, etc..\n
- #60: DKIM es una firma digital asim&#xE9;trica aplicada a cada correo para validar que el remitente es quien dice ser.\n
- #61: \n
- #62: \n
- #63: \n
- #64: \n
- #65: \n
- #66: \n
- #67: \n
- #68: Aprofitem la CPU que de nit no fem servir firmant amb el cluster de PHP\nEls nostres servidors SMTP fan de buffer. Aix&#xED; no tenim el proc&#xE9;s parat. Un servidor SMTP ser&#xE0; sempre millor client SMTP que nosaltres.\n
- #69: \n
- #70: \n
- #71: \n
- #72: Per a evitar bloquejar les taules amb consultes llargues. S&#xED; un select tamb&#xE9; bloqueja.\n
- #73: con algunos ajustes en referencia a la transaccionalidad\n
- #74: \n
- #75: \n
- #76: \n
- #77: \n
- #78: \n
- #79: \n
- #80: \n
- #81: \n
- #82: \n
- #83: \n
- #84: \n
- #85: \n
- #86: \n
- #87: Cada uno se como su ...erda.\n
- #88: \n
- #89: Procurem que la gent faci les seves hores i no m&#xE9;s. Cal estar descansats.\nOdiem l&#x2019;stress.\n
- #90: MTTR = Mean Time To Recovery (o Resolve)\n
- #91: \n
- #92: \n
- #93: \n
- #94: \n
- #95: \n
- #96: Parlem de netejar cach&#xE9;s, APC, etc?\n\n
- #97: Parlem de netejar cach&#xE9;s, APC, etc?\n\n
- #98: Parlem de netejar cach&#xE9;s, APC, etc?\n\n
- #99: Parlem de netejar cach&#xE9;s, APC, etc?\n\n
- #100: Parlem de netejar cach&#xE9;s, APC, etc?\n\n
- #101: Parlem de netejar cach&#xE9;s, APC, etc?\n\n
- #102: \n
- #103: \n
- #104: \n
- #105: \n
- #106: Parla d&#x2019;etsy\n
- #107: \n
- #108: Preguntar quantes persones pensen que som?\n
- #109: Explicar que confiem amb les persones i la seva responsabilitat\nQue busquem el balan&#xE7; entre lo personal i lo professional\nQue la gent quan porta moltes hores currant fa fallos\nQue intentem mantenir el Focus. \nMultidisciplinar\n
- #110: he comptat uns 12 servidors per ofx\n
- #111: \n
- #112: \n
- #113: \n